Access keys: retry a generated ID that is already stored, and check the IAM user on MongoDB imports #824

What happens

create_access_key generates the ID AKIAEXTENDDB followed by 8 characters from A-Z0-9, so there are 36^8 IDs, about 2.8 × 10^12. Across the creation of a million keys, the chance that one creation draws an ID that is already stored is about 16%.

• PostgreSQL and SQLite answer an internal error for that request, and MongoDB does the same with fix(storage-mongodb): store each access key ID once #823. The caller can send the request again.
• Cassandra writes the key with INSERT ... IF NOT EXISTS. create_access_key_impl in crates/storage-cassandra/src/management_store/access_keys.rs does not read the result of apply_lwt, which says whether the insert applied. On a collision it returns a new secret for an ID that another key holds. That secret never authenticates, and the other key does not change.

On MongoDB, import_access_key stores the key without a check that the IAM user exists. SQLite and Cassandra answer 404 "IAM user not found", and the foreign key of PostgreSQL's access_keys table refuses the row. An IAM user can import a key only for itself, so this affects imports by an admin.

Suggested change

• On every backend, generate a new ID and try again a few times when the generated ID is already stored.
• On Cassandra, answer an error when the insert of a new key did not apply.
• On MongoDB, check that the IAM user exists before the import, as the other backends do.

Found while working on #823.