In #16217 we switched clients using Consul discovery to the `Status.Members`
endpoint for getting the list of servers so that we're using the correct
address. This endpoint has an authorization gate, so this fails if the anonymous
policy doesn't have `node:read`. We also can't check the `AuthToken` for the
request for the client secret, because the client hasn't yet registered so the
server doesn't have anything to compare against.

Create a new `Status.RPCServers` endpoint that mirrors the `Status.Peers`
endpoint but provides the RPC server addresses instead of the Raft
addresses. This fixes the authentication bug but also ensures we're only
registering with servers in the client's region and not in any other servers
that might have registered with Consul.

This changeset also expands the test coverage of the RPC endpoint and closes up
potential holes in the `ResolveACL` method that aren't currently bugs but easily
could become bugs if we called the method without ensuring its invariants are
upheld.

Co-authored-by: tantra35 <ruslan.usifov@gmail.com>

We don't really have to worry about regions in the Consul discovery step. If we
hit a different region and they're federated, the request will be forwarded. If
the regions aren't federated (not a very safe topology in general), the node
registration will fail and we'll retry.

Eliminate the region tags we added to Consul. Have `registerNode` update the
server list based on the response we get, and have it return the "no servers"
error if we get no servers so that we kick off discovery again and retry
immediately rather than 15s later.