Combine (re)sharding hash rings in a single type, update split-by-shard logic

[timvisee]

Tracked in #4213.

This combines (re)sharding hash rings in a single type, replacing the single hash ring we had before. It provides a consistent interface for all scenarios, whether we have a single hash ring or multiple while resharding. It keeping most of the existing logic intact, and allows us to extend and/or tweak behavior in a single place in the future.

Here I propose to replace the initial approach with a separate hash ring on a shared resharding key introduced in #4216. It seems more future proof, easier to manage, and remains on the shard key level. When working with shards, we always namespace to a specific shard key and so it makes sense to combine all necessary state in a single type with a single lookup.

It doesn't only replace the way of storing a resharding hash ring, but also updates all point-to-shard routing to spread to two shards in case of resharding.

All Submissions:

• Contributions should target the dev branch. Did you create your branch from dev?
• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. Does your submission pass tests?
2. Have you formatted your code locally using cargo +nightly fmt --all command prior to submission?
3. Have you checked your code using cargo clippy --all --all-features command?

[ffuugoo]

Overall, LGTM! Thanks for taking over it! 👍

My only real comment would be: we might not want to always split-by-shard to new hashring, when doing resharding. E.g., we might want to introduce explicit stages when we do (or do not) split-by-shard to the new shard.

I'd go and add explicit .take(1) to the point_to_shards results, so that this PR won't change current behavior yet.

And then we will introduce another PR that will update split-by-shard logic, so that it would properly split only when required.