CurrentState() messages are probably causing OldUserSpaceSession to remain alive

(Bug, Investigate , Priority: Critical, Test Status: No automated tests yet , Reported By Justin du Coeur, )
Summary: This isn't critical until people are using the Arisia Volunteers Space hard, but has the potential to crash the server during Arisia itself, so it must be fixed!
The problem is that OldUserSpaceSession is a TimeoutChild. That uses setReceiveTimeout() to passivate the session after N minutes, if the session itself hasn't received any messages.
Problem: during Arisia runtime, we are likely to be getting Space changes -- specifically, new Hours records -- on a very frequent basis, often more than once a minute. Space updates cause CurrentState() messages to be sent to all live Sessions. So those Sessions are likely to never time out!
This becomes critical because this is a large Space -- probably multiple megabytes. This might not be a problem, because each individual Session's view is highly trimmed -- in particular, Volunteers only get to see a tiny fraction of the records -- but it's still likely to cause huge GC pressure at best, as well as tons of excess load, since each of those Sessions needs to be doing some computation for every CurrentState(). The system's going to work far better if Sessions can be timed out correctly.
This needs validation, but looking at the code, I think it's true. This bug has probably always been true, but hasn't been noticeable before because we haven't had any Spaces that were being constantly updated.
The fix for this is hopefully straightforward -- we just need to add the NotInfluenceReceiveTimeout trait to CurrentState(). See the Akka docs here and here for details. I haven't tried this one before, so play with it and make sure it works. In principle, we really only case about ClientRequests, and a few other user-initiated messages, for purposes of the timeout.