We currently don't initialize hash rings correctly when custom sharding is used.

Specifically, when custom sharding is used, we also initialize a hash ring for the None key. I'd argue this is not correct.

This PR changes the shard holder loading behavior to not create the None hash ring anymore. We now strictly define what kind of sharding is used, and derive the default rings from there.

We had a production cluster panicking on resharding because no shard key was provided. Loading the hash rings as described in this PR would have prevented the panic with a graceful error. Applying this fix on a cluster that is already in a crash loop due to this problem will resolve the issue.

This PR adds some tests to ensure we check the shard count precondition before resharding. It also ensures we don't crash like we did before.

Tried with:

PUT collections/test
{
  "vectors": {
    "distance": "Cosine",
    "size": 1
  },
  "sharding_method": "custom"
}

POST collections/test/cluster
{
  "create_sharding_key": {
    "shard_key": "test",
    "shards_number": 2
  }
}

POST collections/test/cluster
{
  "start_resharding": {
    "direction": "down",
    "shard_key": null
  }
}

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?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you successfully ran tests with your changes locally?