…ER LOGIN = false

It's straightforward to have the coordinator of the DROP / ALTER
disconnect the impacted client, but non-coordinators don't have a direct
path of finding out that a user has been impacted. The role update
causes a write to system_auth.roles, and non-coordinators will pick up
that change async when they refresh their RolesCache.

It's important for this patch that non-coordinators also disconnect the
impacted user, because we could be revoking the role due to account
takeover or other risk.

One approach to solve this is having all instances periodically check
all their active connections, and disconnect impacted users. The active
connection count default maximum is 10k, and the list of active
connections is scanned for various metrics collection anyway.

Another approach is to limit the maximum duration that any connection
can be established, so users are required to re-authenticate
periodically, like every 24h. This improves our security posture in
other ways, and makes it easier to detect nodes that are added to the
cluster but cannot be accessed by clients.

For either approach, it would be helpful to have a JMX call that allows
operators to disconnect users by name, particularly for handling account
takeover scenarios.

Periodic disconnection would be useful for a few other reasons:
- When using mTLS, clients with short-lived certificates that don't
  support live certificate reloading would be required to
  re-authenticate periodically
- Security requirements that clients re-authenticate periodically,
  rather that depending on bounce schedules to enforce that

…sable invalid role disconnect, null handling