bcrypt is intentionally CPU-expensive (workfactor 12 is ~100ms of CPU per
verification). An unauthenticated client can send repeated auth attempts and
saturate every core, causing a denial of service.

PR ClickHouse#87115 added an LRU cache keyed on SHA256(password) + bcrypt hash, which
absorbs floods that reuse the same credential: after the first miss, repeats
are O(1) cache hits. But the cache is keyed on the password, so an attacker
sending a different password each request misses every time and runs a full
bcrypt_checkpw per attempt. CacheBase::getOrSet serializes only same-key
threads, so distinct passwords all run bcrypt concurrently. The per-user
FAILED_SEQUENTIAL_AUTHENTICATIONS quota does not help: it is opt-in and does
not cover unknown usernames.

This adds a process-wide cap on the number of bcrypt verifications running
concurrently, applied only on the cache-miss path inside getOrSet's load
function so cache hits stay completely unthrottled. Admission is fail-fast:
a thread that cannot get a slot throws AUTHENTICATION_FAILED rather than
blocking, so a flood cannot pile up connection threads and amplify the DoS.
The throw surfaces as the generic authentication error (no information
disclosure) and is not cached, so a legitimate client retrying under lower
load succeeds. Rejections are counted by the BcryptAuthenticationThrottled
profile event.

The cap is a new server config key max_concurrent_bcrypt_authentications,
plumbed through AccessControl::setupFromMainConfig next to bcrypt_workfactor.
It defaults to 0 (unlimited), so behavior is unchanged unless configured.

Together with ClickHouse#87115 this bounds worst-case bcrypt CPU to
concurrency * cost(workfactor) regardless of how many distinct passwords are
tried: the cache absorbs repeats, the cap absorbs the distinct-password flood.
Being identity-agnostic, it cannot be abused to lock out a specific user.

Adds a unit test for the limiter (admission, release, move semantics, the
bound under contention) and an integration test covering the three behaviors:
cache hits unthrottled, concurrent distinct-password floods capped, and 0
preserving unlimited behavior.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Like bcrypt_workfactor, the setting is read once at startup via
AccessControl::setupFromMainConfig and is not re-applied by SYSTEM RELOAD
CONFIG, so a restart is required for a change to take effect. Add a doc note
matching bcrypt_workfactor's reload behavior.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The concurrency limiter rejected an over-the-limit bcrypt verification by
throwing out of checkPasswordBcrypt. That exception propagated through
IAccessStorage::authenticateImpl's per-method loop, aborting it. A user may
list several authentication methods as alternatives (e.g. bcrypt_password and
plaintext_password); the loop tries the next method only when the current one
returns Fail. So a throttled bcrypt method wrongly rejected a login that a
later method (here plaintext) would have accepted.

Make limiter denial behave like a failed bcrypt method: return false so the
loop continues, matching how every other method in checkBasicAuthentication
reports a failed check. Denial is signalled out of the cache load function via
a sentinel that escapes getOrSet uncached, so a correct password throttled once
is not cached as wrong and still authenticates under lower load.

The denial still increments BcryptAuthenticationThrottled and the worst-case
bcrypt CPU is still bounded; only the loop-aborting behavior changes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Two warnings-as-errors flagged by arm_tidy on the new code:

1. hicpp-exception-baseclass on the throttle sentinel in
   AuthenticationData.cpp. The sentinel must be thrown (not returned)
   so it escapes CacheBase::getOrSet uncached, otherwise a correct but
   throttled password would be cached as wrong. Derive BcryptThrottled
   from std::exception to satisfy the check. It is caught locally in
   checkPasswordBcrypt and never reaches a client, so behavior is
   unchanged: throttling still reports a failed bcrypt method.

2. clang-analyzer-cplusplus.Move / hicpp-invalid-access-moved in
   gtest_bcrypt_concurrency_limiter.cpp, which called acquired() on a
   moved-from guard. Restructure MoveTransfersOwnership to verify move
   semantics through observable in_flight accounting (move out of an
   inner scope, then confirm the single slot is still held and is freed
   only when the owning guard is destroyed) without touching the
   moved-from object.

No functional change; the limiter, multi-method fall-through, and
both-directions behavior are unchanged. unit_tests_dbms passes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>