Redesign @Stateful EJB clustering

The current @Stateful EJB clustering design has a number of flaws:

• The current implementation is very slow. Each EJB invocation results in 4 Infinispan transactions! Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
• An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
• Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
• The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
• The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
• State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
• The @Clustered annotation currently has 2 orthogonal meanings:
  1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
  2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.
• Eager passivation is unnecessarily expensive, and makes the eventual SFSB removal slower.