[BP 7.0.2] - XDCR - remoteClusterRef sanInCertificate not being set for full encryption

Pre-7.0, when contacting a remote cluster that is > 4.0 version, the sanInCertificate variable for a remote cluster reference will be set to true.

This is evident from the log message as follows

2021-08-18T10:33:58.988-07:00 INFO GOXDCR.RemClusterSvc: Set hostName=127.0.0.1:9001, httpsHostName=127.0.0.1:19001, SANInCertificate=true HttpAuthMech=Https for remote cluster reference remoteCluster/LvKr93CauVrLkxVJ2ljxtMpoixEBWDrEGPpkh2r_zuc=

Since all supported cluster is now >4.0, there was no need to check against said version. The change to remove this check was introduced as part of changeset to MB-44823.
Specifically http://review.couchbase.org/c/goxdcr/+/152288/3/utils/utils.go#b2682, the sanInCertificate that should have been set to true, was mistakenly not being returned as such.

This leads to create messages like the following once a full-encryption secure reference is created (note the SANInCertificate change from <7.0):

2021-08-18T10:14:52.263-07:00 INFO GOXDCR.RemClusterSvc: Set hostName=127.0.0.1:9001, httpsHostName=127.0.0.1:19001, SANInCertificate=false HttpAuthMech=Https for remote cluster reference remoteCluster/irMfuRAJh98VHg9Qz6dC94Eu7T8XBaplccOVfgDxc8U=

Without SANInCertificate being set to true, there can be situations where REST commands come back with errors such as:

certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0, statusCode=0

The hint is that the error messages asked to "use SANs", where pre 7.0, the SANInCertificate is set to true so this error would have not shown up.

The workaround is to add the environment variable GODEBUG=x509ignoreCN=0, thus why it is not marked a blocker.
Regardless, this needs to be fixed and backported to 7.0.2.