pgsql: libpq: handle GSS credentials more sanely.

libpq: handle GSS credentials more sanely.

pg_GSS_have_cred_cache() always acquires new GSS credentials.
If we already had some, they were just leaked due to overwriting
conn->gcred, and that's a nontrivial amount of memory (around 16K
according to reporter). Unfortunately, pg_GSS_continue() did this
each time through, and it is typically called more than once in a
GSSAPI connection cycle. So repeated connections using GSS
authentication could leak substantial amounts of memory.

IMO the source of this problem is really the poorly-designed API
of pg_GSS_have_cred_cache(): it's unclear that it always gets new
credentials. Let's rename it and remove the unnecessary pointer
parameter to make its behavior clearer.

To add insult to injury, pg_GSS_continue() shouldn't even be
trying to acquire credentials unless GSS delegation is enabled,
which it is not by default; so the whole effort is often wasted.

Problems evidently introduced by 6633cfb21, so back-patch to v16.

Bug: #19411
Reported-by: Matt Carter <Matt(dot)Carter(at)twosigma(dot)com>
Diagnosed-by: Matt Carter <Matt(dot)Carter(at)twosigma(dot)com>
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Discussion: https://postgr.es/m/19411-0440c8897a04b638@postgresql.org
Backpatch-through: 16

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/94d625f5d938e0a01cb80d85cc242ff8a64b3f54

Modified Files
--------------
src/interfaces/libpq/fe-auth.c | 10 ++++++----
src/interfaces/libpq/fe-connect.c | 16 +++++++++++-----
src/interfaces/libpq/fe-gssapi-common.c | 15 ++++++---------
src/interfaces/libpq/fe-gssapi-common.h | 2 +-
src/interfaces/libpq/fe-secure-gssapi.c | 4 ++--
5 files changed, 26 insertions(+), 21 deletions(-)