In SPM-4217 we introduced the 'rawData' argument to all database commands (PR). In the case that 'rawData' is true, for any command that supports this argument, we should treat any timeseries collection as a normal collection. This is because when 'rawData' is specified, the user is instructing to operate on the raw data buckets without unpacking / timeseries translation (as is normally done in a ts operation).

Currently in this project, we have various 'isRawDataOperation(opCtx)' calls scattered around the query code to support these cases. However, a better / more generic solution would be to encapsulate these calls within the various "Collection"-like classes that answer questions about the type of the collection / if it is timeseries. If these classes answer that the collection is a "Normal" collection when 'rawData' is specified, higher level callers of the Collection classes will not have to check themselves in a variety of edge cases and can treat the query like any normal query not on a timeseries collection, without themselves needing the context of if the operation is on 'rawData'.

This should lead to an overall more modular design, with more separation of concerns.

I haven't done an exhaustive audit of every type of class that generically encapsulates a Collection, but here are some / most:

• Collection::isTimeSeriesCollection
  • Implemented by: CollectionImpl::isTimeseriesCollecton
• CollectionOrViewAcquisition::getCollectionType
• MongoProcessInterface::getCollectionType
  • CommonMongodProcessInterface::getCollectionType
    • This one looks like it just calls CollectionOrViewAcquistiion::getCollectionType
  • ShardServerProcessInterface::getCollectionType
    • This one looks like it calls through to listCollections cmd - not sure if it needs to be updated, or covered through other changes
• OpDebug::getCollectionType

Some of these calls may just call through to other ones, so the assignee will have to investigate what the minimum set of changes to implement this change are