Revert MB-34751: Don't Dynamically Change Offered SASL Mechanisms Based on External Auth Being Configured

MB-34751 is a legitimate improvement, but we addressed it in the wrong way and we need to revert it.

The problem that MB-34751 highlights is a fundamental issue that we have multiple authentication systems but they don't expose the same interface in terms of authentication (SASL) mechanisms. Specifically:

• users authenticated locally have PLAIN and SCRAM-SHA based digest auth mechanisms available
• users authenticated externally (in LDAP via direct connection or via saslauthd) only have PLAIN available - we don't support SCRAM-SHA with LDAP users

The fix in MB-34751 was to dynamically change the list of offered SASL mechanisms to only include PLAIN if external auth is configured, with the idea that we should only offer a mechanism if it can work for all users. While on the surface a reasonable idea (that I myself supported) it doesn't work for the following reason: clients who can only use digest auth can suddenly find themselves unable to log in / create a connection against Couchbase Server at runtime when external auth is configured. The problem for these clients is that the system becomes immediately unavailable and client reconfiguration is required (using TLS.)

This case happened in the field recently: XDCR had been configured with the "half-secure" option which requires using SCRAM-SHA. When the target cluster was upgraded to 6.5, since in this case saslauthd had been set up, XDCR replication ceased.

The solution is to revert to the old behavior and find the best way we can to help LDAP users figure out why they can't log in and that they need to connect via TLS (or be ok with disclosing their password in the clear on the wire.)