Context: Many commits ago, a check was added to skip running findOne() on empty collections until non-blocking sort was enabled for clustered collections. According to the TODO, the check can now be removed from the resharding::data_copy::findDocWithHighestInsertedId.

Although the check may actually be an optimization we wish to keep, we should investigate the side effects in case other things in resharding change and it becomes an issue in the future. 

Reproduction:

• Change: Remove the empty collection check here. The only difference: findDocWithHighestInsertedId runs a findOne() before returning boost::none on the empty, temporary resharding collection
• Outcome: invalidate_plan_cache_entries_when_collection_generation_changes.js expects to find 0 plan cache entries for the resharded collA, but finds one entry and fails.

  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] [
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 	{
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"version" : "2",
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"queryHash" : "620FE6DB",
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"planCacheKey" : "AB020F45",
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"isActive" : true,
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"works" : NumberLong(0),
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"timeOfCreation" : ISODate("2023-01-26T15:58:10.228Z"),
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"cachedPlan" : {
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 			"slots" : "$$RESULT=s9 $$RID=s10 env: { s1 = TimeZoneDatabase(Europe/Prague...US/Michigan) (timeZoneDB), s2 = Nothing (SEARCH_META) }",
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 			"stages" : "[3] limit 1 \n[2] nlj inner [] [s7, s3, s4, s6, s5] \n    left \n        [1] nlj inner [s4, s5] [] \n            left \n                [1] project [s4 = \"_id_\", s5 = {\"_id\" : 1}] \n                [1] limit 1 \n                [1] coscan \n            right \n                [1] project [s3 = s8] \n                [1] ixseek KS(F0FE04) KS(0A0104) s6 s7 s8 [] @\"eb54438c-3161-4dd2-bb9b-5eac443ff9a8\" @\"_id_\" false \n    right \n        [2] limit 1 \n        [2] seek s7 s9 s10 s3 s4 s6 s5 [] @\"eb54438c-3161-4dd2-bb9b-5eac443ff9a8\" true false \n"
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		},
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"indexFilterSet" : false,
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"isPinned" : true,
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"estimatedSizeBytes" : NumberLong(5497),
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"host" : "ip-10-122-12-243:20040",
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 		"shard" : "invalidate_plan_cache_entries_when_collection_generation_changes-rs0"
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] 	}
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] ]
  [js_test:invalidate_plan_cache_entries_when_collection_generation_changes] [jsTest] ----
  

Question: Is it expected for the findOne() on the temporary resharding collection to remain as a plan cache entry? 

Hypothesis: The findOne() run on the temporary resharding collection and when the collection is renamed, collIIsDropped is false by default, and _cleanupBeforeInstallingNewCollectionMetadata does not clean up the plan cache entry (SERVER-65492). The temporary sharding collection is renamed to collA, and keeps the same UUID it had when the findOne() was issued. Then, when the test checks for the absence of plan cache entries tied to collA, it finds an entry with collA's new UUID.