Separate Spring Session Data Store implementations

[rwinch]

Spring Session 1.x provides all Spring Session Data Store implementations in the same jar. This is convenient, but it makes for a number of disadvantages:

• The jar becomes larger the more data store implementations that are added
• Due to being centralized within Spring Session it puts a strain on Spring Session committers who do not know every data store implementation. This strain slows development of new data stores and prevents additional features from being implemented
• It makes the documentation complicated. Right now there is a division between XML, Java Config, & Boot. Each of those is divided by data store and each of those is divided by features (i.e. Servlet integration, Spring Security integration, find by username support, etc). This makes it very difficult to document and read. Breaking up by data store simplifies the document structure which makes reading and writing easier.

The plan going forward is to externalize each of the Data Store implementations. Modules that have an owner that is a Spring Team committer will be maintained within spring-projects. Modules that do not have an official commiter will be maintained externally. We will provide links to each implementation to make it easier for users to find.

Modules that wish to participate should follow the same version of the core Spring Session module. Any version that shares the same major and minor version (i.e. only varies by the patch version) should work with one another. This means that if Spring Session is on 2.1.x and a new project wants to participate it should start with version 2.1.0.RELEASE.