adapter: Reject reserved role specification names in CREATE ROLE

[ggevay]

Fixes SQL-502

Motivation

CREATE ROLE CURRENT_USER used to create a role literally named
current_user. PostgreSQL rejects CURRENT_USER, CURRENT_ROLE,
SESSION_USER, USER, and NONE as role names because they act as role
specifications in statements like GRANT ... TO CURRENT_USER, where a role
with such a name would be ambiguous. Found via the CockroachDB logic test
import (#37459).

Description

CREATE ROLE now rejects the role names current_user, current_role,
session_user, user, and none with "role name ... is reserved", the same
way it already rejects public and the mz_/pg_ prefixes. The new names
are added to is_reserved_role_name, the single choke point that covers role
creation via SQL, role creation via JWT group sync, and pgwire login
validation.

The check is on the normalized (lowercase) name rather than at parse time.
PostgreSQL rejects the unquoted keyword forms while still allowing the quoted
spelling CREATE ROLE "current_user", but our lexer does not treat these
words as keywords and does not track whether an identifier was quoted, so the
quoted lowercase forms are rejected too. That is a small deviation from
PostgreSQL that errs on the safe side: a role named current_user is exactly
the ambiguity being prevented. Quoted spellings that do not normalize to a
reserved lowercase name, such as CREATE ROLE "CURRENT_USER", remain valid,
as in PostgreSQL. GRANT ... TO PUBLIC and friends are unaffected.

Verification

Added regression tests to test/sqllogictest/role.slt covering all six
reserved names (quoted and unquoted) plus the allowed quoted-uppercase case,
and a unit test in group_sync.rs pinning the is_reserved_role_name
contract. Edge-case behavior (which names PostgreSQL rejects, with which
messages, quoted vs. unquoted) was compared against a live PostgreSQL 18.

🤖 Generated with Claude Code