The _onCleanup() implementation for ChunkOperationShardingCoordinator does update the chunk operation statistics, keeping tracks of the overall number of  chunk operations succeeded or failed.
The ShardingCoordinator::run() completion path currently invokes the _onCleanup() cleanup hook only when the execution status is OK, this apparently looks wrong, because we do want to also update the statistics when the chunk operation fails (status is not OK).

The reason this is not actually a bug is that the merge-chunk error path, split-chunk error path, and move-range error path always invoke  triggerCleanup() when they hit an error during coordinator execution.

In fact when triggerCleanup() is invoked we enter the abort-recovery path, which have the guarantees to always return an ok status. The actual coordinator error is in instead stored separately in the coordinator document and finally extracted into the completionStatus variable. 

On the other side triggerCleanup() performs a majority write and is supposed to be used only when we already into a coordination phase that require modifying a persisted state before exit the coordinator execution (e.g. releasing the critical section, re-enabling chunk operations etc...). Generically triggerCleanup() should be used only when we already executed a phase for which _mustAlwaysMakeProgress() is true. 

The goal of this ticket is to remove the hidden and unnecessary dependency between the _onCleanup() logic and the requirement to always execute the triggerCleanup() error even when completely unnecessary.

Update terminal coordinator cleanup so failed executions also run the cleanup hook, and keep abort-reason persistence only for phases where it is needed to guarantee cleanup and forward progress. Preserve critical-section/resource release while avoiding unnecessary majority writes.