For nested aggregates in a sharded cluster which feature stages like $lookup, we often wind up acquiring multiple CollectionRoutingInfo objects (once at the top level and again when checking the shardedness of the inner collections. On its own, this isn't a problem because usually these involve different collections (so, conceptually, separate CollectionRoutingInfo objects) and ultimately the checks are used to inform routing decisions (that is, choosing the 'wrong' host should mean that we get a suboptimal, but not incorrect, plan). However, there are a few cases that could be pose a problem

• Cases where the target collection is the same as the inner collection
• Cases where we have different collections, but which have the same database (i.e. all $lookup queries). This a problem potentially because the DBversion can change, between checks, indicating either a new owning shard for an unsplittable collection, or that the db was dropped and recreated. 

This ticket tracks the work to investigate whether the cases described above can hit crashes or incorrect query results.