There are places in the codebase where an operation that mostly fits under one service role needs to access behaviors that correspond to a different service role. I suspect many of these have existed from before the notion of a service role was introduced to the codebase. These codepaths will log with misleading service roles and might run into subtle bugs where behaviors from different roles intermix and destructively interfere with one another.

Add explicit support for an OperationContext in one service role accessing the behaviors from another service role in a way that ensures that the context switch is observable both in the code and in externally facing data (i.e. logs). I propose two paths:

• Add an API that allows an OperationContext to temporarily assume a different service role, perhaps using an RAII object to represent the context switch (AlternativeClientRegion might offer what we need for this)
• Document a method whereby an OperationContext can create and own another OperationContext acting in the desired role which will perform actions on the parent OperationContext's behalf (and add any accompanying APIs as needed)

Once support is in place, ensure that the ResourceYielders introduced in SERVER-85526 do not violate the property that an OperationContext always uses behaviors from its own service role. In particular, ensure that ShardResourceYielderFactory does not directly use TransactionRouter. Further, investigate the codebase for other places where role switching is needed.