storage-cassandra: migrate, verify and settings hang when the superuser password is not the stock one #726

On Cassandra, extenddb migrate, extenddb verify and extenddb settings hang when the Cassandra superuser no longer has the stock cassandra/cassandra password, which is the case on any cluster set up for real use.

The settings, management and diagnostics store factories build their session in make_catalog_store_from_connection_string (crates/storage-cassandra/src/lib.rs:263-302 at f49c5f8). The connection string carries only the contact points and the keyspace prefix, and the function authenticates with hard-coded StaticPasswordAuthenticatorProvider::new("cassandra", "cassandra"), with datacenter1 and replication factor 1 also fixed. It ignores both the username/password in [storage.cassandra] and the --cassandra-user/EXTENDDB_CASSANDRA_PASSWORD that migrate takes. When that login is refused, the driver retries without a deadline, so the command never returns.

Callers:

• extenddb migrate: CatalogResourceTagStep::open(app_config.storage.connection_config()) (crates/app/src/cmd_migrate.rs:117) opens a management and a settings store this way, after the bootstrapper (which does use the supplied superuser credentials) has connected.
• extenddb verify: create_settings_store at crates/app/src/cmd_verify.rs:52.
• extenddb verify also opens the diagnostics store the same way (cmd_verify.rs:92).
• extenddb settings: create_settings_store at crates/app/src/cmd_settings.rs:60.

serve, init, manage and healthcheck are not affected: serve builds its session from the full config, and manage and healthcheck go through the HTTP API.

Measured on main at f49c5f8 with one cassandra:4.1.12 node running PasswordAuthenticator, the superuser password changed with ALTER ROLE cassandra WITH PASSWORD = '...', and a catalog created by init:

• extenddb migrate --config ... --yes --cassandra-user cassandra with EXTENDDB_CASSANDRA_PASSWORD set prints HybridClock initialized ... and makes no further progress; killed after 120 s and again after 300 s.
• extenddb verify --config ... prints --- Checking catalog connection... and makes no further progress; killed after 60 s.
• With the stock superuser password left in place, the same migrate --yes completes.

None of the Cassandra CI jobs catch this, because integration-cassandra.yml only ever logs in as cassandra/cassandra.

Effect on 1.0: since 0.1.14, serve refuses a catalog that migrate has not marked, so an existing Cassandra deployment that changed its superuser password cannot be upgraded. The Cassandra container image being prepared for 1.0 (#725) runs migrate in its release smoke test, so its release fails until this is fixed.

#681 replaces make_catalog_store_from_connection_string with a session built from the role the config file names and a 10 s connect bound, which would fix this. Whichever change lands, a Cassandra CI leg that changes the superuser password first, then runs migrate, verify and settings, would keep it from coming back.