Direct SSL connection and ALPN loose ends

There's been a bunch of bugs, and discussion on the intended behavior of
sslnegotiation and ALPN. This email summarizes the current status:

## Status and loose ends for beta1

All reported bugs have now been fixed. We now enforce ALPN in all the
right places. Please let me know if I missed something.

There are two open items remaining that I intend to address in the next
few days, before beta1:

- I am going to rename sslnegotiation=requiredirect to
sslnegotiation=directonly. I acknowledge that there is still some debate
on this: Jacob (and Robert?) would prefer to change the behavior
instead, so that sslnegotiation=requiredirect would also imply or
require sslmode=require, while IMHO the settings should be orthogonal so
that sslmode controls whether SSL is used or not, and sslnegotiation
controls how the SSL layer is negotiated when SSL is used. Given that
they are orthogonal, "directonly" is a better name. I will also take
another look at the documentation, if it needs clarification on that
point. If you have more comments on whether this is a good idea or not
or how sslnegotiation should work, please reply on the other thread,
let's keep this one focused on the overall status. [1]

- The registration of the ALPN name with IANA hasn't been finished yet
[2]. I originally requested the name "pgsql", but after Peter's comment,
I changed the request to "postgresql". The string we have in 'master' is
currently "TBD-pgsql". I'm very confident that the registration will go
through with "postgresql", so my plan is to commit that change before
beta1, even if the IANA process hasn't completed by then.

## V18 material

- Add an option to disable traditional SSL negotiation in the server.
There was discussion on doing this via HBA rules or as a global option,
and the consensus seems to be for a global option. This would be just to
reduce the attach surface, there is no known vulnerabilities or other
issues with the traditional negotiation. And maybe to help with testing. [3]

These are not directly related to sslnegotiation, but came up in the
discussion:

- Clarify the situation with sslmode=require and gssencmode=require
combination, by replacing sslmode and gssencmode options with a single
"encryption=[ssl|gss|none], [...]" option. [4]

- Make sslmode=require the default. This is orthogonal to the SSL
negotiation, but I think the root cause for the disagreements on
sslnegotiation is actually that we'd like SSL to be the default. [5]

The details of these need to be hashed out, in particular the
backwards-compatibility and migration aspects, but the consensus seems
to be that it's the right direction.

## V19 and beyond

In the future, once v17 is ubiquitous and the ecosystem (pgbouncer etc)
have added direct SSL support, we can change the default sslnegotiation
from 'postgres' to 'direct'. I'm thinking 3-5 years from now. In the
more distant future, we could remove the traditional SSLRequest
negotiation altogether and always use direct SSL negotiation.

There's no rush on these.

## Retrospective

There were a lot more cleanups required for this work than I expected,
given that there were little changes to the patches between January and
March commitfests. I was mostly worried about the refactoring of the
retry logic in libpq (and about the pre-existing logic too to be honest,
it was complicated before these changes already). That's why I added a
lot more tests for that. However, I did not foresee all the ALPN related
issues. In hindsight, it would have been good to commit most of the ALPN
changes first, and with more tests. Jacob wrote a python test suite; I
should've played more with that, that could have demonstrated the ALPN
issues earlier.

[1]
https://www.postgresql.org/message-id/CA%2BTgmobV9JEk4AFy61Xw%2B2%2BcCTBqdTsDopkeB%2Bgb81kq3f-o6A%40mail.gmail.com

[2]
https://mailarchive.ietf.org/arch/msg/tls-reg-review/9LWPzQfOpbc8dTT7vc9ahNeNaiw/

[3]
https://www.postgresql.org/message-id/CA%2BTgmoaLpDVY2ywqQUfxvKEQZ%2Bnwkabcw_f%3Di4Zyivt9CLjcmA%40mail.gmail.com

[4]
https://www.postgresql.org/message-id/3a6f126c-e1aa-4dcc-9252-9868308f6cf0%40iki.fi

[5]
https://www.postgresql.org/message-id/CA%2BTgmoaNkRerEmB9JPgW0FhcJAe337AA%3D5kp6je9KekQhhRbmA%40mail.gmail.com

--
Heikki Linnakangas
Neon (https://neon.tech)