Description of bug blocking this work:
We are in the process of converting some functions that accept StringData as a parameter for a database name to accept DatabaseName objects instead.  While converting the lone validateViewDefinitionBSON entry in DurableViewCatalog, we uncovered a separate bug exposed by this correction.

validateViewDefinitionBSON is being called by onExternalChange in the original implementation with the database name toString (which includes the tenantId).  validateViewDefinitionBSON performs a string comparison on the database name being passed in vs. the view name from the BSONObj being passed in as part of its validation, which will fail when comparing a database name without the tenantId against one with the tenantId.  When this happens, DurableViewCatalog::onExternalInsert catches the failure and its caller, OpObserverImpl::onInserts, fails silently and re-routes to DurableViewCatalog::onExternalInsert instead.  This results in following a different code path that calls CollectionCatalog::reloadView(), which does not perform the same checks.  In other words, the call to DurableViewCatalog::onExternalInsert will never succeed.

When applying our changes and passing in the correct database name values, validateViewDefinitionBSON now passes and viewName is locally being created in onExternalInsert, but not being locked prior to calling CollectionCatalog::createView(), where an invariant checks that viewName is being locked, causing the failure in the correct code path.

TODO in this ticket:
Change the dbName parameter in validateViewDefinitionBSON to take a DatabaseName obj.