Allowing SSL connection of v11 client to v10 server with SCRAM channel binding

HI all,

When a client connects during a SCRAM exchange, it has multiple ways
to let the server know what the client supports or not when using
channel binding:
- "n" -> client doesn't support channel binding.
- "y" -> client does support channel binding but thinks the server does not.
- "p" -> client requires channel binding.

On a v10 client, we just need to use the "n" flag because the client
does not support channel binding. This way, a v10 client can connect
to a v10 or v11 server with or without SSL, and this even if the
server has published the SASL mechanism SCRAM-SHA-256-PLUS, which is
used to define channel binding use during SCRAM authentication.

With a v11 client though, things are more fancy:
- If the server publishes the SCRAM-PLUS mechanism, then the client
replies with a "p" message. We are here in the context of an SSL
connection. This is the case of a v11 client, v11 server.
- If using an SSL connection, and the server did not publish
SCRAM-PLUS, then the client uses "y". This is the case of a v11 client
and v10 server.
- For a non-SSL connection, "n" is used. (The server would not have
sent the -PLUS mechanism anyway). This happens for all combinations
without SSL.

When using "n" or "y", the data sent by the client to the server about
the use of channel binding is a base64-encoded string of respectively
"n,," (biws) and "y,," (eSws). However, as noticed by Peter E here, a
v10 server is able to allow connections with "n,,", but not with
"y,,":
https://www.postgresql.org/message-id/887b6fb7-15fe-239e-2aad-5911d2b0945b@2ndquadrant.com

When trying to connect to a v11 client based on current HEAD to a v10
server using SSL, then the connection would fail. The attached patch,
for REL_10_STABLE, allows a server to accept as well as input "eSws",
which is a combination that can now happen. This way, a v10 server
accepts connections from a v11 and newer client with SSL.

Thoughts?
--
Michael