Divide each store to its own crate about tower-sessions

[czocher]

Yep I strongly believe since they are dependencies, cargo will load them all no matter the feature flags, but best to confirm it with a test.

[czocher]

Unfortunately I didn't have the time to perform the test.
The easiest way to do it would be to switch the version of dependencies in a way that makes the subdependencies incompatible with one another.
The earliest I can try this test is in January though.

[maxcountryman]

Since we're publishing separate crates currently, does this mean that we should not re-export those crates via feature flags from the main crate? (I think this will lead to the issue you're describing.)

[maxcountryman]

That being the case, I don't think it'll be too difficult to move toward removing the feature flags since we're done the work of physically separating stores into their own crates.

It's maybe also worth taking a second look at sqlx and how they approach this: I think they're able to get away with this because there's no problem with all SQL engines being enabled at the same time.

[maxcountryman]

@czocher were you able to determine that the feature flags indeed cause the interaction that you mentioned here? If so, should we proceed by removing the feature flags in tower-sessions and instead have applications require stores as separate deps?

[maxcountryman]

I think from a UX perspective, it might be cleaner to require session stores as dependencies anyway, omitting the feature flags altogether.

One downside is that testing these stores might become more cumbersome. (Or perhaps we require the same set of stores we currently have as dependencies of the integration test suite.)