Prior to MongoDB 5.0 it wasn't possible for an external client to create a system.buckets collection, even if such a client was authenticated as the __system user. This is because collections which are prefixed with system. are protected at a level outside the access control system where unrecognized system collections cannot be created (full stop). With the introduction of timeseries collections in MongoDB 5.0, this constraint was relaxed and it became possible for external clients to create system.buckets collections directly. The intended use case was likely for mongorestore for performance reasons to directly write the bucket documents. However despite the only valid use case for system.buckets collection to be for a timeseries collection, this isn't actually enforced by the server at all.

This gap in input validation leaves open a risk where Server engineers make poor assumptions about NamespaceString::isTimeseriesBucketsCollection() implying the collection is actually timeseries without consulting the local mdb catalog. Or where mongosync wants to rely on checking whether the namespace has a system.buckets. prefix and therefore requires special DDL handling to deal with the associated view namespace. We should instead move the server semantics into one where the assumptions engineers are making turn out also to be true.

rs:PRIMARY> db.dropDatabase()
rs:PRIMARY> db.system.buckets.a.runCommand("create")
{
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1690936687, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1690936687, 1)
}