PATCH: warn about, and deprecate, clear text passwords

There have been a few complaints lately about the fact that we cavalierly
allow clear text passwords to be sent when doing CREATE USER or ALTER USER.
These, of course, can end up in many places, such as pg_stat_activity,
pg_stat_statements, .psql_history, and the server logs. It is a genuinely
valid complaint, and for security purposes, there is little recourse other
than telling users "don't do that". The canonical recommendation is to use
psql's awesome \password feature. Second best is to use your
application/driver of choice, which hopefully has support for not sending
passwords in the clear.

Please find attached a patch to implement a new GUC called
cleartext_passwords_action as an attempt to solve these problems. It is an
enum and accepts one of three values:

1. "warn" (the new default)

This issues a warning if a clear text password is used, but allows the
change to proceed. The hint can change to recommend \password if the
current application_name is 'psql'. By keeping this as a warning, we let
people know this is a bad idea, and give people time to modify
their applications.

Examples:

ALTER USER alice PASSWORD 'mynewpass';
WARNING: using a clear text password
DETAIL: Sending a password using plain text is deprecated and may be
removed in a future release of PostgreSQL.
HINT: Use a client that can change the password without sending it in
clear text

ALTER USER eve PASSWORD 'anothernewpass';
WARNING: using a clear text password
DETAIL: Sending a password using plain text is deprecated and may be
removed in a future release of PostgreSQL.
HINT: If using psql, you can set the password with \password

2. "allow"
This does nothing, and thus emulates the historical behavior.

3. "disallow"
This prevents the use of plain old text completely, by throwing an error if
a password set or change is attempted. So people who want to prevent clear
text can do so right away, and at some point we can make this the default
(and people can always change to hint or allow if desired)

Bike shedding welcome. I realize the irony that 'disallow' means valid
attempts will now show up in the database logs that otherwise would not,
but I'm not sure how to work around that (or if we should).

--
Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support