Review of GetUserId() Usage

Greetings,

While looking through the GetUserId() usage in the backend, I couldn't
help but notice a few rather questionable cases that, in my view,
should be cleaned up.

As a reminder, GetUserId() returns the OID of the user we are
generally operating as (eg: whatever the 'role' is, as GetUserId()
respects SET ROLE). It does NOT include roles which we currently have
the privileges of (that would be has_privs_of_role()), nor roles which
we could SET ROLE to (that's is_member_of_role, or check_is_... if you
want to just error out in failure cases).

On to the list-

pgstat_get_backend_current_activity()
Used to decide if the current activity string should be returned or
not. In my view, this is a clear case which should be addressed
through has_privs_of_role() instead of requiring the user to
SET ROLE to each role they are an inheirited member of to query for
what the other sessions are doing.

pg_signal_backend()
Used to decide if pg_terminate_backend and pg_cancel_backend are
allowed. Another case which should be changed over to
has_privs_of_role(), in my view. Requiring the user to SET ROLE for
roles which they are an inheirited member of is confusing as it's
generally not required.

pg_stat_get_activity()
Used to decide if the state information should be shared.
My opinion is the same as above- use has_privs_of_role().
There are a number of other functions in pgstatfuncs.c with similar
issues (eg: pg_stat_get_backend_activity(),
pg_stat_get_backend_client_port(), and others).

Changing these would make things easier for some of our users, I'm
sure..

Thanks!

Stephen