The aggregate command creates an entry in Top by using the AutoGetCollectionOrViewForReadCommand RAII class, but the lifetime of this object is shorter than the time we spend processing the command. It's declared within an inner scope here so that we can release the locks before we start executing the Pipeline (which is self-locking). This will cause the Top entry to be generated too early: right after we construct the execution machinery, but before we actually execute the pipeline.

Further, we recursively call runAggregate() when we are running an aggregate command on a view. This creates two oddities/problems:

1. We will create another AutoGetCollectionOrViewForReadCommand in the recursive call, which will generate another Top entry.
2. During the recursive call call, the 'outer' AutoGetCollectionOrViewForReadCommand object from the calling frame is still in scope, so that Top entry will include the execution time of the entire 'runAggregate', including execution time.