PS-11143-[8.4] sql/auth: quiesce caching_sha2_password before teardown

[lukin-oleksiy]

https://perconadev.atlassian.net/browse/PS-11143

Guard caching_sha2_password entry points during plugin shutdown so auth/cache accesses drain before the singleton is destroyed.

This avoids use-after-free on the rwlock-backed password cache in in-flight authentication paths, including threadpool worker threads.

Also simplify the lifecycle bookkeeping by keeping it in one small file-scope state object and using the existing scope guard helper for cleanup.

[jankowsk]

That solves the problem of unloading the plugin while an authentication is ongoing. It
would work providing the authentication is never called after deinit. Are we sure this condition is met?

[lukin-oleksiy]

Generally, how it works (8.4):

do_auth_once() locks the auth plugin (my_plugin_lock_by_name(...)), calls auth->authenticate_user(...), then unlocks it (plugin_unlock(...)) in sql/auth/sql_authentication.cc (around lines 3535-3557).
UNINSTALL PLUGIN sets plugin state to PLUGIN_IS_DELETED in sql/sql_plugin.cc (2612), and unloading is deferred until ref_count == 0 (2613-2617, 1194-1216).
A plugin lock only succeeds for PLUGIN_IS_READY or PLUGIN_IS_UNINITIALIZED states (intern_plugin_lock, 961-987 in sql/sql_plugin.cc), so once marked deleted, new lock attempts fail.
If a thread already had the plugin locked before uninstall, that in-flight auth call can still complete safely; physical deinit/unload happens only after it unlocks.
After unload/deletion for new requests, auth function cannot be called through normal server flow; server returns plugin-not-loaded path (ER_PLUGIN_IS_NOT_LOADED) in do_auth_once() when lock fails (3558-3563).

So, conclusion is: we are safe when unloading is complete.