Improve handling of CCR threadpool rejections

[DaveCTurner]

The CCR threadpool uses a fixed executor with default size 32 and default queue length 100, which means it rejects work if overloaded. However, it does not look like we handle these rejections very gracefully in several spots, even though the overload might be a transient situation:

• ShardChangesAction.TransportAction#asyncShardOperation adds a GCP listener to run on the ccr pool, which if rejected looks like it might suppress some other notifications and propagate up into the ReplicationTracker.
• ShardFollowTasksExecutor is a PersistentTasksExecutor which executes the task on the ccr pool, and on rejection the task is just marked as failed.
• ShardFollowTasksExecutor#nodeOperation also just fails the task.
• ShardFollowNodeTask#scheduleBackgroundRetentionLeaseRenewal uses scheduleWithFixedDelay which just stops running the scheduled task on rejection.
• AutoFollower#finalise looks like it might call itself ad infinitum on rejection?
• CcrRepository#restoreShard uses scheduleWithFixedDelay which just stops running the scheduled task on rejection. Possibly this is ok? If the restore fails I expect we will retry.

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)