Rename the remote cluster sniff proxy setting

[Tim-Brooks]

In order to use the "proxy" name for the new connection mode, the
existing cluster.remote.cluster_name.proxy setting must be renamed
to cluster.remote.cluster_name.sniff.proxy. This commit implements
this change and adds a setting upgrader. Since the setting is not
documented, the old setting is immediately removed. Finally, the
settings upgrader infrastructure is modified so that settings that are
not registered with the cluster can be upgraded.

[elasticmachine]

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

[Tim-Brooks]

This commit is necessary for #50291. Otherwise the news settings cannot be added.

[ywelsch]

There are some relevant REST tests failing. I also wonder how the upgrade path for a rolling upgrade will look like.

[ywelsch]

?

[Tim-Brooks]

After looking into this, I am not sure if using the name proxy is going to work. As I investigated the rolling restart tests I had two concerns:

1. It seems like there might be races between when our settings upgraders run. For example a node might upgrade its cluster state on a restart, but that might be overwritten when it receives the cluster state from another node.
2. A concern for this specific issue, newly upgraded non-master nodes will receive a cluster state with a setting that does not exist anymore. It is tricky to figure out the implications of this, but I was seeing the setting changed to be prefixed by "archived." which is the marker of an invalid setting.

I am open to any discussions about how to resolve this issue. If there is some safe way to ensure the handling of a removed setting I can go that direction. But we can also consider other names such as cluster.remote.cluster_name.proxy_mode.address. Maybe in that case we would want to name to also be cluster.remote.cluster_name.sniff_mode.seeds.

[Tim-Brooks]

This PR will probably be closed in favor of #50291.

[Tim-Brooks]

Closing. We are not moving in this direction.