Re: [EXT] Re: GSS Auth issue when user member of lots of AD groups

I wrote:
> I believe we've agreed that it'd be sufficient if we allow the
> packets exchanged during the auth phase to be up to 64K or so,
> but once we reach the point where we're able to split the
> data on arbitrary boundaries, keep the packet size at 16K
> for cross-version compatibility.

OK, here's a set of draft patches for that.  (The HEAD one works
on v16 and v17 too, the v15 one works on v14 too.  They are all
basically the same, but we kept revising libpq's internal convention
for error reports ...)

I am not in a great position to test these with a setup that actually
needs larger auth messages; I wonder if Chris can test?

Some notes:

* Is 128kB unreasonably large?  I think we may want some daylight
above 64kB, but I'm not sure how much.

* I concluded that the error report that's being given for the case
is just flat-out bogus.  The GSSAPI library has not given us an
error report so asking it for info is useless, which leads to the
very unhelpful error message Chris showed.  We should just report
"client tried to send oversize GSSAPI packet" as we do elsewhere.

* It seems pretty silly to have separate symbols for
PQ_GSS_SEND_BUFFER_SIZE and PQ_GSS_RECV_BUFFER_SIZE
when we're requiring those to be the same, so I merged
them into one symbol PQ_GSS_MAX_PACKET_SIZE.

* The backend's secure_open_gssapi allowed received initialization packets
to be up to buffer-size long, whereas libpq will choke sending them
if they're more than buffer-size minus sizeof(uint32).  This isn't
actually a bug, since the buffer management is handled in such a way
that it's safe, but it seems very inconsistent.  I changed the limit
to subtract off sizeof(uint32) in all cases, which incidentally
allowed removing one variant of the translatable message string.

            regards, tom lane