The delete path calls OpObserver::onDelete() (here and here) in order to log a delete op in the oplog.

Again similar to inserts/updates, OpObserverImpl::onDelete() constructs oplog entries differently depending on whether the op is part of a multi-document transaction or not. If it is part of a transaction, we construct the oplog entry by calling MutableOplogEntry::makeDeleteOperation. Add tenantId as a boost::optional parameter to MutableOplogEntry::makeDeleteOperation so that we can set the "tid" field on the ReplOperation constructed there if featureFlagRequireTenantId is set. If the op is not part of a transaction, we call replLogDelete. Grab the tenantID from NamespaceString in replLogDelete, and set the "tid" field on the entry there.

Let's again add a test case to the OpObserverImplTest and check that OpObserverImpl::onDelete() behaves as expected when called both in a multi-document transaction and not.