Implementation of SASLprep for SCRAM-SHA-256

Hi all,

Here is another thread for an issue related to SCRAM
(https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74b23@iki.fi)
that can be discussed independently: SASLprep.

RFC5802 (https://tools.ietf.org/html/rfc5802) regarding the
implementation of SCRAM, needs to have passwords normalized as per
RFC4013 (https://tools.ietf.org/html/rfc4013) using SASLprep, which is
actually NFKC. I have previously described what happens in this case
here:
https://www.postgresql.org/message-id/CAB7nPqScgwh6Eu4=c-0L7-cufZrU5rULTSdpMOOWiz1YFvGE6w@mail.gmail.com
This way, we can be sure that two UTf-8 strings are considered as
equivalent in a SASL exchange, in our case we care about the password
string (we should care about the username as well). Without SASLprep,
our implementation of SCRAM may fail with other third-part tools if
passwords are not made only of ASCII characters. And that sucks.

To put in short words, NFKC is made of two steps: a canonical
decomposition of the UTF-8 string (decomposition of the string
following by a reordering using the class of each character), followed
by its recomposition.

Postgres does not have any logic on the frontend-side related to
encoding, still it is possible with some of the APIs of wchar.c to
check if a string provided is valid UTF-8 or not. If the string is not
valid UTF-8, we should just use the string as-is in the exchange,
which leads to undefined behaviors anyway as SASL needs to do things
with UTF-8.

I have also implementation a Postgres extension able to do this
operation, which has been useful for testing.
https://github.com/michaelpq/pg_plugins/tree/master/pg_sasl_prepare

Attached is a patch implementing that, the conversion tables are built
from UnicodeData.txt to be minimal in size. I have added an Open Item
on the wiki for this problem as well.

Thanks,
--
Michael