Similar to the insert path, the update path calls OpObserver::onUpdate() (here and here) in order to log an update op in the oplog.

Again similar to inserts, OpObserverImpl::onUpdate() 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::makeUpdateOperation. Add tenantId as a boost::optional parameter to MutableOplogEntry::makeUpdateOperation 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 should set the "tid" field in replLogUpdate. We can again just grab the tenantId from the NamespaceString object on OplogUpdateEntryArgs.

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