pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

Hi -hackers,

We've got customer report that high max_connections (3k) with high
pgstat_track_activity_query_size (1MB) ends up with:

postgres=# select * from pg_stat_get_activity(NULL);
ERROR: invalid memory alloc request size 18446744072590721024
postgres=# select version();
version
------------------------------------------------------------------------------------------------------
PostgreSQL 17devel on x86_64-pc-linux-gnu, compiled by gcc (Debian
10.2.1-6) 10.2.1 20210110, 64-bit
(1 row)

it's in:
#0 errstart (elevel=elevel(at)entry=21, domain=domain(at)entry=0x0) at elog.c:358
#1 0x000055971cafc9a8 in errstart_cold (elevel=elevel(at)entry=21,
domain=domain(at)entry=0x0) at elog.c:333
#2 0x000055971cb018b7 in MemoryContextAllocHuge (context=<optimized
out>, size=18446744072590721024) at mcxt.c:1594
#3 0x000055971ce2fd59 in pgstat_read_current_status () at backend_status.c:767
#4 0x000055971ce30ab1 in pgstat_read_current_status () at backend_status.c:1167
#5 pgstat_fetch_stat_numbackends () at backend_status.c:1168
#6 0x000055971ceccc7f in pg_stat_get_activity (fcinfo=0x55971e239ff8)
at pgstatfuncs.c:308

It seems to be integer overflow due to (int) * (int), while
MemoryContextAllocHuge() allows taking Size(size_t) as parameter. I
get similar behaviour with:
size_t val = (int)1048576 * (int)3022;

Attached patch adjusts pgstat_track_activity_query_size to be of
size_t from int and fixes the issue.

Regards,
-Jakub Wartak.