JBossCacheManager active session count should include backup sessions

The usage of the max active session configuration in JBossCacheManager currently only applies to sessions that are being used in the local node – it ignores how many sessions are stored in the distributed cache. This makes little sense, since the primary purpose of controlling the session count is to control memory resources. A session in the distributed cache takes memory resources just as much as a locally used one does.

With this change, when the Manager checks whether there are excess sessions, the maxActive property value will be compared against an "active" count derived as follows:

visible sessions = count of locally accessed sessions + count of sessions in the local instance of the distributed cache that have not been locally accessed
active sessions = visible sessions - sessions passivated locally

The value of that calculation is what will be returned by the getActiveSessionCount() method.

If the active session count >= maxActive, the session expiration/passivation method (processExpires()) will be executed before a new session is created. If after expiration/passivation the active session count still exceeds maxActive, the session creation request will be rejected with an IllegalStateException. (Rejecting the attempt to create excess sessions is not new; all that has changed is the calculation.)

The same comparison is used within processExpires() to determine whether sessions that have reached their configured passivation-min-idle-time need to be passivated.

Note that the value of "active sessions" will depend on whether the distributed cache is using buddy replication, as that will impact the number of sessions stored in the local instance of the distributed cache:

1) If buddy replication is disabled, a copy of all sessions used on any node in the cluster will be stored in the local instance of the distributed cache.

2) If buddy replication is enabled (the default in 5.x), only sessions hosted by cluster nodes for which the current node is serving as a buddy will be stored in the local instance of the distributed cache.