Feature: Add explicit `FLUSH PRIVILEGES`-style command to refresh role cache across query nodes

[TCeason]

Summary

• CI spins up a 3-node query cluster via scripts/ci/deploy/databend-query-cluster-3-nodes-nginx.sh, then tests/nox/java_client/prepare.py creates user
  databend, role test_jdbc, and runs GRANT ALL ON *.* TO ROLE test_jdbc.
• Grants are written in meta by whichever node handles the HTTP call (through nginx on port 8000).
• JDBC sessions are routed round-robin to any query node. Each node maintains its own RoleCacheManager (src/query/users/src/role_cache_mgr.rs), which
  invalidates locally on GRANT/REVOKE but otherwise reloads every 15 s via background polling or lazy maybe_reload.
• If a JDBC session lands on a different node before its cache reloads, validate_db_access (src/query/service/src/interpreters/access/privilege_access.rs:268- 337) sees stale grants and throws:

Permission denied: privilege [Create] is required on 'default'.'default'.*

• CI currently has to curl each node (SHOW GRANTS FOR ROLE test_jdbc on ports 8001–8003) to force reloads, which is brittle.

Request

Introduce an explicit “flush privileges” mechanism, similar to MySQL/ClickHouse:

• Provide a SQL statement (e.g. SYSTEM FLUSH PRIVILEGES / SYSTEM RELOAD ROLES) and/or HTTP API that invokes RoleCacheManager::force_reload(&tenant) on
  every query node.
• Broadcast the command so all running query instances refresh immediately, eliminating the 15 s window.

Acceptance Criteria

• After GRANT/REVOKE the user can run a single flush command and be guaranteed that all nodes observe the new privileges immediately.
• CI scripts no longer need to probe each HTTP port manually to warm caches.

[TCeason]

This issue can not be good first issue.

[camilesing]

I think this is a more suitable issue for beginners, and I think my current implementation is good. Do you have any good suggestions for this? @TCeason

[TCeason]

I think this is a more suitable issue for beginners, and I think my current implementation is good. Do you have any good suggestions for this? @TCeason

ref this comment: #19052 (comment)

[TCeason]

I think this is a more suitable issue for beginners, and I think my current implementation is good. Do you have any good suggestions for this? @TCeason

1. Currently, SYSTEM FLUSH PRIVILEGES only refreshes the RoleCacheManager for the current node using self.ctx.get_tenant(). However, when InterpreterSystemAction broadcasts the same SystemPlan to other compute nodes via Flight, the remote system_action creates a brand-new session object using create_session(). This session directly uses the default tenant from GlobalConfig::instance().query. tenant_id (see src/query/service/src/servers/flight/v1/actions/mod. rs:46-49), and is completely unaware of the original tenant of the request.
2. Since the SystemPlan itself does not carry tenant information, remote nodes can only refresh the cache for the default tenant. If the SQL was executed under a non-default tenant, the actual tenant cache on those nodes will not be refreshed. Those nodes will only see the new permissions after the 15-second polling interval or the next lazy load, which violates the acceptance criterion of the issue: "All nodes should immediately observe the new permissions."

Suggested Fix:
Explicitly include the tenant in the SystemPlan (or attach it to the Flight message), so that remote nodes can call RoleCacheManager::force_reload for the correct tenant in SystemActionInterpreter::execute2.

If you are interested, I can assign this issue to you. Looking forward to your reply

[camilesing]

I understand. Sorry, I was careless. plz assign it to me, let me continue trying it @TCeason