Cassandra: extenddb init does not fully configure extenddb #470

Following the Cassandra setup guide, extenddb init --backend cassandra does not get a user to a running server. After init, serve fails until the user hand-edits the generated config, and clusters are required to use the "allow-all" authorizer (not CassandraAuthorizer). Issues were confirmed during the review of PR #412 (Cassandra documentation), by building the branch and following the guide; the docs now describe the broken-but-real behavior. This issue tracks fixing the behavior so the docs can describe a working path.

1. --replication-factor is read but never declared

bootstrapper.rs reads --replication-factor via extract_arg (bootstrapper.rs:77), but InitArgs in cmd_init.rs never
declares the flag. clap parses InitArgs first and rejects the flag before the bootstrapper runs:

$ extenddb init --backend cassandra --replication-factor 3 ...
error: unexpected argument '--replication-factor' found

Same class as #267 (--sqlite-path).

Fix: declare replication_factor: Option on InitArgs with #[arg(long)]. The existing bootstrapper read and the
conflict check at bootstrapper.rs:150 then work.

2. Application credentials are written commented out

init creates the application role (extenddb / extenddb-local-dev by default), but the generated [storage.cassandra section has username/password commented out, showing placeholder values (cassandra / cassandra-password) rather than the role it created. serve then connects unauthenticated and fails:

extenddb fatal: Failed to connect to cassandra: Connection error: Connection timeout after 10s.

Setting the two fields to the role init created makes serve start and /health return healthy. PostgreSQL and MongoDB write a working connection string; Cassandra is the outlier.

Fix: write a config serve can use as-is. Options: write username/password live and uncommented set to the created
role; or reference an env var (EXTENDDB_APP_PASSWORD is already the preferred password input) from the config. Either is fine: the requirement is that init → serve works without a hand-edit.

3. Datacenter is hardcoded to datacenter1

The bootstrapper hardcodes datacenter: "datacenter1" (bootstrapper.rs:229), writes it to the config (:694), and offers
no flag. Keyspaces use NetworkTopologyStrategy referencing datacenter1, so a cluster whose local DC has any
other name fails:

Unrecognized strategy option {datacenter1} passed to NetworkTopologyStrategy for keyspace extenddb_catalog

Fix: add a --datacenter init flag (default datacenter1), threaded to the keyspace DDL and the written config — same
path as --replication-factor (do both together).

4. The application role is granted no permissions

init runs CREATE ROLE ... WITH PASSWORD AND LOGIN = true (bootstrapper.rs:288) but no GRANT. Under
CassandraAuthorizer, serve fails:

User extenddb has no SELECT permission on

Only AllowAllAuthorizer works today.

The grant must scope to the deployment's keyspaces (catalog + per-account under keyspace_prefix). Per-account
keyspaces are created after init, and Cassandra has no wildcard/pattern grant, so grants can't all happen at init
time: the per-account keyspace-creation path must grant the role as each keyspace is made.

Fix: issue GRANT SELECT/MODIFY/... ON KEYSPACE TO at each keyspace's creation (bootstrapper
for the catalog keyspace, the per-account path for account keyspaces). Then CassandraAuthorizer is supported.

Done when

• init
  --backend cassandra against an authenticated node, followed by serve, reaches a healthy server with no manual config edit.
  --replication-factor and --datacenter are accepted and take effect.
• A role created by init works under CassandraAuthorizer.
• docs/cassandra-setup.md and docs/getting-started.md are updated to drop the workarounds this issue removes.