Always consider adjacent teams when moving shards

One goal of data distribution is to minimize the number of shards to reduce the size of the txnStateStore (which in turn reduces recovery times).

To reduce the number of shards with the existing algorithm, one step we can take would be that if two adjacent shards are assigned to the same team, do not add a key separating them in the txnStateStore. It is possible the separating key still exists in the database so that if data distribution is restarted it knows about the shard boundary.

Once adjacent shards assigned to the same team cost less, we can change the data distribution algorithm to favor having adjacent shards assigned to the same team. By including the teams of adjacent shards as possibilities in the getTeam algorithm, we will be more likely to choose them while still balancing data across teams. There is some risk of creating hot write shards with this approach so that will need to be handled carefully.

In addition, the mountain chopper and valley filler could also consider optimizing the number of shards when they balance data.

Start by reading the data distribution algorithm around getTeam, then examine how the txnStateStore represents shard boundaries. Review the mountain chopper and valley filler balancing paths as well. Done means adjacent shards can be coalesced when assigned to one team, team selection favors adjacency without creating hot write shards, and balancing also considers shard-count reduction.

Written by the indexing model from the issue text.