swift-manage-shard-ranges should refuse to find ranges in an already-sharded DB

[Tim Burke]

So I've already got a sharded DB; it's got some 800+ objects, split across shards with 250, 250, 300+ objs:

vagrant@saio:~/swift$ swift-manage-shard-ranges /srv/node2/sdb2/containers/15/cae/0f65ef68c2db3f0768374d15c9a14cae/0f65ef68c2db3f0768374d15c9a14cae_1621373542.84707.db info
Loaded db broker for AUTH_test/c
Sharding enabled = True
Own shard range: {
  ...
  "name": "AUTH_test/c",
  "object_count": 847,
  ...
}
db_state = sharded
Metadata:
  ...
vagrant@saio:~/swift$ swift-manage-shard-ranges /srv/node2/sdb2/containers/15/cae/0f65ef68c2db3f0768374d15c9a14cae/0f65ef68c2db3f0768374d15c9a14cae_1621373542.84707.db show
Loaded db broker for AUTH_test/c
Existing shard ranges:
[
  {
    ...
    "lower": "",
    "object_count": 250,
    "upper": "swift/common/middleware/crypto/encrypter.py"
  },
  {
    ...
    "lower": "swift/common/middleware/crypto/encrypter.py",
    "object_count": 250,
    "upper": "swift/examples/wsgi/container-server.wsgi.template"
  },
  {
    ...
    "lower": "swift/examples/wsgi/container-server.wsgi.template",
    "object_count": 347,
    "upper": ""
  }
]

... but if I forget that I've already found shard ranges and go to find a fresh set...

vagrant@saio:~/swift$ swift-manage-shard-ranges /srv/node2/sdb2/containers/15/cae/0f65ef68c2db3f0768374d15c9a14cae/0f65ef68c2db3f0768374d15c9a14cae_1621373542.84707.db find 250
Loaded db broker for AUTH_test/c
Namespace(conf_file=None, force_commits=False, func=<function find_ranges at 0x7ff5a6f0ad30>, path_to_file='/srv/node2/sdb2/containers/15/cae/0f65ef68c2db3f0768374d15c9a14cae/0f65ef68c2db3f0768374d15c9a14cae_1621373542.84707.db', rows_per_shard=250, subcommand='find', verbose=0)
[
  {
    "index": 0,
    "lower": "",
    "object_count": 847,
    "upper": ""
  }
]
Found 1 ranges in 0.00190997s (total object count 847)

... it "helpfully" offers to throw everything back into a single shard that's way more than the rows-per-shard I specified. I'm guessing it just went ahead and tried to find splits on the records in the actual objects table (which was empty).

Seems better for us to bail when we see that the DB's sharded (so we don't expect it to actually have any object rows).