Currently, the join_plan_cache_invalidation_md.js test assumes that certain indexes are used by the plan but explain shows they are not:

• the STPs are expected to use single_table_predicate_1 on the single table access to base_coll but explain shows COLLSCAN instead.
• a_1 is expected to be used on base_coll but base_coll is the outer side of the join and instead the lookup_coll's a_1 index is used to drive the INLJ.

SERVER-132841 makes the join plan cache distinguish an index the cached plan reads from
one that was merely relevant. Dropping or hiding a relevant index the plan does not read
no longer invalidates, which is the intended behavior. Because of the assumption above,
the following cases assert invalidation for indexes the plan never used, and now report
Cache entry was expected to be invalidated but was not!:

• Hiding the index on the base collection's single-table predicate
• Hiding the index on the $lookup collection's single-table predicate
• Dropping and recreating an index with a different keyPattern (different sparseness)
• Dropping and recreating an index with a different keyPattern (different collation)