sql: add e2e tests and fix privilege bug for DROP PROVISIONED ROLES

[souravcrl]

Add comprehensive logic tests for the DROP PROVISIONED ROLES statement
covering end-to-end behavior, LIMIT validation, admin-skip behavior
for non-admin CREATEROLE callers, skip-on-dependency contract for all
seven dependency branches, and expression evaluation.

These tests address the review feedback from @rafiss on #166980
(review)
which called out the lack of integration/logic tests, no coverage of
skip-on-dependency branches, no test of admin-skip behavior for
non-admin callers, and no test of the CREATEROLE-only caller path.

The execution layer enforces a mandatory LIMIT clause to prevent
accidentally dropping an unbounded number of provisioned roles in a
single transaction. The LIMIT must be a constant integer between 1
and 1024. This safety guard was added during implementation but
lacked test coverage until now.

Tests cover:

• LIMIT is mandatory (error without it)
• LIMIT validation (0, negative, >1024, subquery expression)
• Provisioned users are dropped, non-provisioned remain untouched
• root/admin users are never dropped
• SOURCE filter drops only matching source
• LIMIT caps the number of dropped users
• LAST LOGIN BEFORE time-based filtering
• Combined filters with LIMIT
• Non-CREATEROLE user is rejected
• Non-admin CREATEROLE caller: admin provisioned users are silently
  skipped while non-admin provisioned users are dropped (contrast
  with DROP ROLE which errors on admin users)
• All seven dependency skip branches:
  1. Grants on objects
  2. Ownership of objects
  3. System privileges (e.g. VIEWCLUSTERMETADATA)
  4. Default privileges (explicit role)
  5. Default privileges (per-object grantee)
  6. Row-level security policies
  7. Scheduled jobs ownership
• Empty match returns no error
• Multiple sources filtered correctly
• Role memberships cleaned up on drop
• Parse roundtrip
• Expression evaluation for SOURCE (concatenation) and LAST LOGIN
  BEFORE (now() - interval arithmetic) — verifies that non-literal
  expressions are properly type-checked and evaluated at execution
  time rather than being stringified

Also re-applies the NodeUserSessionDataOverride fix for the find
query. The find query originally used NodeUserSessionDataOverride
but was changed to params.p.User() during review to use lower
privileges. However, the AI reviewer on #166980 correctly
identified that a user with only CREATEROLE privilege cannot
directly read system.users, system.scheduled_jobs, or
system.privileges, so the dependency check and find queries would
get permission errors at runtime. The fix to
NodeUserSessionDataOverride was applied but got overwritten during
a force-push from a separate worktree. Authorization is already
checked at plan time via CheckGlobalPrivilegeOrRoleOption, and the
query is hardcoded with only parameterized filter values.

Fixes: #170030
Fixes: #170031
Fixes: #170032
Fixes: #170048
Epic: CRDB-54682
Release note: None

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[blathers-crl]

Your pull request contains more than 1000 changes. It is strongly encouraged to split big PRs into smaller chunks.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[github-actions]

Bug: Pre-existing panic on NULL filter expressions. The evalFilterExprs method (lines 255-271) uses tree.MustBeDString and tree.MustBeDTimestampTZ on the result of eval.Expr, which returns tree.DNull when the user passes NULL. Since the grammar accepts a_expr and TypeCheckAndRequire allows types.UnknownFamily, NULL passes all checks and causes a server panic at runtime. Any CREATEROLE user can crash the node with DROP PROVISIONED ROLES WITH SOURCE = NULL LIMIT 10;. This bug predates this PR but should be fixed — add a d == tree.DNull check after each eval.Expr call in evalFilterExprs and return pgerror.Newf(pgcode.InvalidParameterValue, "SOURCE/LAST LOGIN BEFORE filter cannot be NULL").

[github-actions]

AI Review: Potential Issue(s) Detected

An inline comment has been added to the relevant line in the diff.

Bug: Server panic on NULL filter expressions in DROP PROVISIONED ROLES (High severity)

In pkg/sql/drop_provisioned_roles.go:255-271, the evalFilterExprs method calls tree.MustBeDString (line 260) and tree.MustBeDTimestampTZ (line 268) on the result of eval.Expr, which returns tree.DNull when the user passes NULL. The grammar accepts a_expr (including NULL) for both SOURCE and LAST LOGIN BEFORE, and TypeCheckAndRequire allows types.UnknownFamily through. This means any user with CREATEROLE privilege can crash the server node with:

DROP PROVISIONED ROLES WITH SOURCE = NULL LIMIT 10;
DROP PROVISIONED ROLES WITH LAST LOGIN BEFORE NULL LIMIT 10;

Suggested fix: After each eval.Expr call in evalFilterExprs, check for d == tree.DNull and return a user-facing error (e.g. pgerror.Newf(pgcode.InvalidParameterValue, "SOURCE filter cannot be NULL")).

Minor: SHOW vs DROP inconsistency for NULL estimated_last_login_time (Low severity)

The DROP query (drop_provisioned_roles.go:297-299) uses IS NULL OR in its filter, matching users who never logged in, while SHOW ROLES ... LAST LOGIN BEFORE intentionally excludes them. This means a SHOW preview won't match what DROP actually deletes.

---

View full analysis

If helpful: add O-AI-Review-Real-Issue-Found label.
If not helpful: add O-AI-Review-Not-Helpful label.