This change modifies the notablescan semantics. Previously if a collection was clustered and the notablescan option was set a plan involving a clustered index scan would be rejected due to the notablescan.

Note that this PR will be backported to all supported LTS versions

Description of Linked Ticket

On a clustered collection when notablescan is enabled:

• Query to delete multiple documents using a secondary index on the primary.  Eg., db.coll.remove({x:{$gte:0}}), where an index is defined for the field x.
• We replicate oplog entries to delete documents on the secondary replica by _id
• On the secondary, the deletion is not done by the indexed field x but by _id.  However, the query system doesn't recognize the clustered index as a real _id index, and it fails. This causes a crash of the secondary replica.

In this scenario, the plan for the delete by _id on the secondary would include a CLUSTERED_IXSCAN and thus should not be blocked by the notablescan setting.

The solution is to fix the planner logic to allow CLUSTERED_IXSCAN with the notablescan setting.

See the repro script in the comment below and see the code here