keymigrate: fix conversion of transaction hash keys

[creachadair]

In the legacy database format, keys were generally stored with a string prefix
to partition the key space. Transaction hashes, however, were not prefixed: The
hash of a transaction was the entire key for its record.

When the key migration script reads scans its input, it checks the format of
each key to determine whether it has already been converted, so that it is safe
to run the script over an already-converted database.

After checking for known prefixes, the migration script used two heuristics to
distinguish ABCI events and transaction hashes: For ABCI events, whose keys
used the form "name/value/height/index", it checked for the right number of
separators. For hashes, it checked that the length is exactly 32 bytes (the
length of a SHA-256 digest) AND that the value does not contain a "/".

This last check is problematic: Any hash containing the byte 0x2f (the code
point for "/") would be incorrectly filtered out from conversion. This leads to
some transaction hashes not being converted.

To fix this problem, this changes how the script recognizes keys:

1. Use a more rigorous syntactic check to filter out ABCI metadata.
2. Use only the length to identify hashes among what remains.

This change is still not a complete fix: It is possible, though unlikely, that
a valid hash could happen to look exactly like an ABCI metadata key. However,
the chance of that happening is vastly smaller than the chance of generating a
hash that contains at least one "/" byte.

Similarly, it is possible that an already-converted key of some other type
could be mistaken for a hash (not a converted hash, ironically, but another
type of the right length). Again, we can't do anything about that.

[tychoish]

Similarly, it is possible that an already-converted key of some other type
could be mistaken for a hash (not a converted hash, ironically, but another
type of the right length). Again, we can't do anything about that.

This, at least, I think is safe because we get all legacy keys and store them in a slice in memory during the run of the test, so if the migration finishes in one go we're safe (and it's idempotent as long as hashes don't look like legacy key-hashes, though I suppose that was always a risk.)

[creachadair]

Similarly, it is possible that an already-converted key of some other type
could be mistaken for a hash (not a converted hash, ironically, but another
type of the right length). Again, we can't do anything about that.

This, at least, I think is safe because we get all legacy keys and store them in a slice in memory during the run of the test, so if the migration finishes in one go we're safe (and it's idempotent as long as hashes don't look like legacy key-hashes, though I suppose that was always a risk.)

The problem is that on the second pass we might think the already converted key is a legacy hash, and try to convert it. If we're lucky the conversion will fail and report an error; otherwise we will pack the new key into a hash record and destroy its antecedent.