History for the SI Playtesting Space is OOM'ing

(Bug, Closed -> Fixed, Priority: Critical, Test Status: Unit tested , Reported By Justin du Coeur, )
History
Summary: Pretty much all History-related operations in the Playtest Space are causing java.lang.OutOfMemoryError: GC overhead limit exceeded -- the telltale sign that we've been too profligate with RAM, and are now paying the price.
Sigh -- this isn't 100% astonishing, but I had hoped we were never going to hit this problem. The issue isn't subtle or entirely surprising: it's caused by the fact that the SpaceHistory reads the entire History into RAM, and stores it there in the Actor. That was always an iffy proposition, and now we're paying the price for the fact that I didn't grok the right approach when I originally built it.
Basically, SpaceHistory, and everything related to it, needs to be rewritten to be stream-oriented instead. If the history member survives at all, it must be in a very limited form; ideally, it would go away entirely.
Some parts of this should be straightforward -- for example, findAllDeleted() is already stream-ish, so rewriting it to be folding over the incoming history records instead of the in-memory ones shouldn't be hard. Similarly, RollbackTo should be fairly easy.
RestoreDeletedThing() is going to be much slower, since it will have to scan the entire History to find the last version that existed. In order to support bulk undelete, we should probably enhance that to be able to restore many Things in a single pass.
Can we just remove FindAllStomped? The OID bug was many years ago, so we may be able to call that one dead.
GetHistoryVersion() is conceptually straightforward, but it's problematic to have to fetch it on every user call. This probably warrants an enhancement to OldUserSpaceSession, to store the current history state and reuse it, rather than fetching it for every SessionRequest.
The hardest problem is actually the UI. Currently, that fetches the entire History; that was always a little daft, but now it's downright broken. It should instead send a parameter saying which versions to fetch, and only fetch some reasonable subset at a time -- at most a thousand records. The backend would maintain a running window of that many versions while dealing with the request. The UI would need back and forward buttons to be able to step further back through the history -- that would be slow, but at least it should work.