Refactor ndc history resender to handle multiple remote clusters

[yycptt]

What changed?

• Refactor ndc history resender to handle multiple remote clusters

Why?

• Existing history resend is bind to particular remote cluster and can't be used for resending history from other remote clusters. This means we need to create one resender for each remote cluster and also worry about cluster metadata update.
• Needed by Guarantee history task execution #2864, so that we don't need to refactor existing standby task executor implementation (or creating multiple standby executors and add callback for cluster metadata update) but still be able to handle standby tasks which need to resend history from different remote clusters.

How did you test it?

• Existing tests

Potential risks

Is hotfix candidate?

[wxing1292]

should the remoteCluster be the active cluster from namespace cache?

[yycptt]

If the question is why we still have one replication task executor for each remote cluster, I think we can refactor that too and have only one executor? cc @yux0

If it's about why not letting xdc resender itself figure out the remote cluster name from ns cache, then I thought about it as well. The main concern is that if the caller can't control which remote cluster the resender is talking to, there might be a mismatch between caller and resender. E.g. when caller is replication task executor for cluster A, the resend may resend from cluster B. Another example is in standby timer/transfer task executor, we may connect to cluster A to refresh task, but may resend history from cluster B. It's rare but will make behavior reasoning much harder.

[yux0]

If the question is why we still have one replication task executor for each remote cluster, I think we can refactor that too and have only one executor?

Yes. We can do this