RUST-1779 Fix a memory leak in cleanup tracking

[abr-egn]

RUST-1779

There turned out to be two issues:

• a straightforward bug where if a command generating a cleanup item finished quickly, that (inert) cleanup item was never removed from the list
• incrementing an id to generate a hashmap key is basically pessimal behavior for hashmaps

To fix the second I switched the storage over to a vec with a secondary list of free indices for efficient removal. The generation tag ensures that a given Id won't remove a value that's re-used that slot in the vec. While the storage vec is never shrunk, the reuse of indices means it'll only grow up to capacity for peak concurrent cleanup operation execution.

[abr-egn]

Note: both evergreen failures are unrelated, it looks like ahash (used by bson) has started pulling in zerocopy v0.7.11, which fails both the MSRV and cargo-deny checks. I've filed https://jira.mongodb.org/browse/RUST-1780 to track that.

[abr-egn]

To fix the second I switched the storage over to a vec with a secondary list of free indices for efficient removal. The generation tag ensures that a given Id won't remove a value that's re-used that slot in the vec. While the storage vec is never shrunk, the reuse of indices means it'll only grow up to capacity for peak concurrent cleanup operation execution.

It turns out this is implemented by the slotmap crate; since the implementation in there is pretty simple, I'm inclined to leave it as-is instead of picking up another dependency.