Figure out the transaction abort state on re-targeting exceptions

Original Description

Single replica-set transactions currently abort transactions unconditionally when an exception occurs. The reason is that the transaction could be holding to a WUOW which needs to get cleaned up. The abort happens here.

This is problematic for some of the sharding machinery that uses exceptions as control flow. Examples include StaleConfigException, CommandOnShardedViewNotSupportedOnMongod, SnapshotTooOld (this makes readConcern: snapshot effectively unusable).

New Description

SERVER-36591 handles retries on snapshot errors, so this ticket will track retries on all other re-targeting errors, i.e. CommandOnShardedViewNotSupportedOnMongod, StaleConfigException, and CannotImplicitlyCreateCollection.

Mongos should be allowed to retry on each of these errors, picking a new atClusterTime only during the first overall statement in the transaction, otherwise using the immutable atClusterTime established during the first statement. Any shards newly added by this statement must include startTransaction=true on its retries, not just the first request sent to them. If mongos exhausts its allowed retry attempts and any of these errors is returned to the client, the response should include the TransientTransactionError label.

Shards can also be modified to only abort their local transaction on these errors if they are encountered on the first statement that shard has seen.