The PR Introduce the RetryPolicy abstraction #2004 replaced AttachmentKeys.commandDescriptionSupplier (it removed the whole concept of attachments in the internal API for retries) with SpecRetryPolicy.onCommand. So currently, the command description, which is usually, if not always, its name (the first key in the BSON representation of the command), is still supplied lazily instead of being passed via the constructor of SpecRetryPolicy.

1. Operations that construct SpecRetryPolicy directly can just pass the command name to the constructor as they always know which command they are constructing SpecRetryPolicy for. This is true even for MixedBulkWriteOperation, which stores the name of the command for the first batch to MixedBulkWriteOperation.commandName in the constructor of MixedBulkWriteOperation, and then updates that field each time it creates the next batch.
2. Operations that use SyncOperationHelper/AsyncOperationHelper.executeRetryable..., could get the command name from CommandCreator without the need to create the whole command for that (currently, there is no such method, but it may be added).

When we do this, we must make sure we are not introducing any additional encoding of a command into a BSON just to get he command name for logging.