storage-controller: keep export descriptions in sync on ALTER SINK and skip no-op connection alters

[ggevay]

Fixes SQL-517

Motivation

GRANT, REVOKE, ALTER ... OWNER, or ALTER CONNECTION on a connection
panicked the coordinator with

altering export connections after txn must succeed: InvalidAlter(AlterError { id: User(...) })

whenever a dependent sink had previously been changed with
ALTER SINK ... SET FROM. Seen in the Nightly Parallel Workload jobs
"rename + naughty identifiers" and "DDL Only".

Root cause: StorageController::alter_export (the ALTER SINK path) sends the
new sink definition to the cluster and updates the ExportState, but never
wrote the new ExportDescription into the collection's DataSource::Sink. The
controller's stored export description therefore kept the sink definition from
sink creation forever. This update was lost when the description moved from
ExportState into CollectionState in 273b3e4 ("Make sinks a variant of
collections").

Any catalog change to a connection item (including privilege and owner changes)
emits a Connection(Altered) implication, which recomputes the connection of
every dependent sink from the catalog and calls alter_export_connections.
That method diffs the new connection against the stale stored description with
alter_compatible, which requires fields like value_desc and
relation_key_indices to match. After an ALTER SINK ... SET FROM had changed
those, the check failed with InvalidAlter, and the coordinator treats that as
a violated invariant and panics.

Description

Two commits:

• Keep the stored export description current on ALTER SINK (the bug fix):
  alter_export now stores the new ExportDescription in the collection state
  after sending the RunSink command, mirroring alter_export_connections.
  With the controller's description tracking the catalog, later connection
  alters diff against the sink that is actually running. This also makes
  run_export rerun the current sink definition instead of the stale one.

• Skip no-op sink connection alters (separable optimization): catalog
  changes that don't affect a connection's runtime config, like GRANT and
  REVOKE, also arrive at alter_export_connections. Previously they
  restarted every dependent sink dataflow for no reason. Skip updates where
  the connection is unchanged, mirroring alter_ingestion_connections. This
  does not mask the bug above: with a stale description the recomputed
  connection differs, so the compatibility check still runs.

User-facing changes:

• GRANT/REVOKE/ALTER on a connection no longer panics the coordinator
  when a dependent sink had been altered with ALTER SINK ... SET FROM.
• Privilege- and owner-only changes to a connection no longer needlessly
  restart dependent sink dataflows.

Verification

• New regression test in test/testdrive/alter-sink.td: GRANT on the sink's
  connection after ALTER SINK ... SET FROM, then verify data still flows.
  Before the fix, a minimal repro (CREATE SINK, ALTER SINK SET FROM, GRANT ON
  CONNECTION) deterministically reproduced the exact panic and backtrace from
  the Nightly failures. After the fix it passes.
• alter-sink.td, connection-alter.td, and kafka-sink-statistics.td (which
  breaks and restores a sink's connection via real ALTER CONNECTION,
  exercising the non-skipped path) all pass with both commits.
• bin/cargo-test -p mz-storage-controller passes.

🤖 Generated with Claude Code