Negotiating the SCRAM channel binding type

Currently, there is no negotiation of the channel binding type between 
client and server. The server advertises that it supports channel 
binding, or not, and the client decides what channel binding to use. If 
the server doesn't support the binding type that the client chose, 
authentication will fail.

Based on recent discussions, it looks like there's going to be 
differences in this area [1]. OpenSSL can support both tls-unique and 
tls-server-end-point. Java only supports tls-server-end-point, while 
GnuTLS only supports tls-unique. And Mac OS Secure Transports supports 
neither one. Furthermore, it's not clear how TLS v1.3 affects this. 
tls-unique might no longer be available in TLS v1.3, but we might get 
new channel binding types to replace it. So this is about to get really 
messy, if there is no way to negotiate. (Yes, it's going to be messy 
even with negotiation.)

I think we must fix that before we release v11, because this affects the 
protocol. There needs to be a way for the server to advertise what 
channel binding types it supports.

I propose that the server list each supported channel binding type as a 
separate SASL mechanism. For example, where currently the server lists:

SCRAM-SHA-256-PLUS
SCRAM-SHA-256

as the supported mechanisms, we change that into:

SCRAM-SHA-256-PLUS tls-unique
SCRAM-SHA-256-PLUS tls-server-end-point
SCRAM-SHA-256

Thoughts? Unfortunately this breaks compatibility with current v11beta 
clients, but IMHO we must fix this. If we want to alleviate that, and 
save a few bytes of network traffic, we could decide that plain 
"SCRAM-SHA-256-PLUS" implies tls-unique, so the list would be:

SCRAM-SHA-256-PLUS
SCRAM-SHA-256-PLUS tls-server-end-point
SCRAM-SHA-256

That would be mostly compatible with current libpq clients.

[1] 
https://www.postgresql.org/message-id/flat/20180122072936.GB1772%40paquier.xyz

- Heikki