XDCR DNS SRV not following RFC2782

There are technically two issues here.

1. XDCR is too literal in terms of hostname box for DNS SRV support.
2. XDCR is taking the DNS SRV record's port name and using it as ns_server's 8091

Some history is that XDCR's hostname field was never meant to be used as a connection string field. It was always meant to be used as a field to enter a node's FQDN or IPv4 or IPv6.

For DNS SRV support (MB-37684), we've now overloaded the hostname field to allow lookup of DNS SRV but without the "couchbase://" nor "couchbases://" URI schemes as described by the SDK Connection String RFC. However, there hasn't been an official approved plan to migrate and consolidate with SDK RFC-0011. For this MB, XDCR will remain URI-less.

Thus, the first issue is that XDCR follows it too directly and is not populating the "service" or "proto" field of the SRV lookup.

Customers and Couchbase Cloud are setting up DNS SRV with records that follow the RFC-0011 standards, which leads to the second issue.

The second issue is that currently XDCR reads the DNS SRV with the port number, and tries to use it as the ns_server port of 8091 and 18091. The port being specified in the SRV records are actually Memcached ports for CCCP bootstrap. XDCR currently doesn't support CCCP.

This means XDCR DNS SRV support can only be "halfway". It cannot be completely compliant with SDK RFC, because of the lack of CCCP.

For now, this means XDCR SRV support can only work if the standard ports 8091 or 18091 are used. Any non-standard ports will not be able to be represented in the DNS SRV records (which breaks the SDK RFC). In the future, if it is necessary and XDCR can bootstrap using CCCP, then we can address the 1) URI scheme and 2) bootstrap off of the SRV records completely (EDIT: now filed as MB-41083)