Should we remove MultiStore implementation?

From the discussion with @smcgivern, about supporting self-managed:

What do we do with self-managed? Do we need to document the transition strategy with MultiStore, or we don't expect that self-managed are going to use Gitlab::Redis::Sessions instances at all?

For rate limiting and trace chunks, we decided not to support self-managed migrations as it probably wasn't necessary. I think that also applies here, because we don't even support migrating from a single Redis (the default) to multiple (cache, shared state, queues, etc.)!

There is also another aspect, the MultiStore is designed to be agnostic to the type of the Redis Store, and it could be possibly reused in the future if we decide to create a new dedicated redis instance for something else (i.e. LoadBalancing). MultiStore allows us to migrate data more easily and less risky.

Even if we remove the MultiStore from the codebase, it would be good to link to it in new_redis_instance docs so we can bring it back if needed in the future.

Edited by Nikola Milojevic