Allow backend connector to apply expiration policies based on HTTP session timeout

[mcollovati]

Kubernetes KIT requests the deletion of session stored by backend connector when the HTTP session expires because of timeout or manual invalidation. However, the HTTP session may be never destroyed when an application node is stopped, leaving orphaned sessions on the backend that may not be restored on another node, for example because the browser tab has been already closed.

To prevent this situation, it should be possible to make the backend connectors apply an expiration policy to each persisted entry. Both Redis and Hazelcast provide such feature.

The expiration time for the stored sessions entries should be computed based on the HTTP session timeout, to avoid eager removal of data. For example, it could be something like HttpSession.getMaxInactiveInterval() * 1.5, letting the data on the backed to live for a while after the assumed HTTP session expiration.

[jorgheymans]

If this is considered for implementation, please consider first the most simple strategy which is to let the developer directly configure a duration which is added to the session creation time to determine expiry. As most teams don't have unlimited session duration and are managing session lifecycle actively they would know of a hard limit after which a session can safely be reaped in the store. A strategy interface for this could then let teams apply more sophisticated expiration policies if needed.