feat: automatically set a default_sequence_kind on DDL failure

[olavloite]

Introduces default_sequence_kind connection property. When DDL execution fails due to a missing sequence kind (detected via regex parsing of the Spanner error message), the driver automatically runs ALTER DATABASE to configure default_sequence_kind, and retries the remaining DDL statements.

Fixes #716

[gemini-code-assist]

Code Review

This pull request introduces automatic handling for DDL statement failures caused by a missing default sequence kind. When such an error is encountered and a 'default_sequence_kind' connection property is configured, the driver automatically executes an 'ALTER DATABASE' statement to set the default sequence kind and retries the remaining DDL statements. The changes also include corresponding unit tests and updates to the in-memory test server. The review feedback suggests simplifying the regular expression used to detect the missing sequence kind error by removing a redundant '.*' prefix.

[olavloite]

Nice feature. When DDL execution fails due to a missing sequence kind, the driver automatically runs ALTER DATABASE to set the default sequence kind and retries the remaining statements.

However, there is a bug in the error/metadata handling:
If a DDL batch of size > 1 fails, the default sequence kind is set, and the driver retries. If the retry succeeds for some statements and then fails again, the returned BatchError computes successful statement counts only from the first execution (op.Metadata()), completely ignoring the statements that succeeded during the retry. We should combine the counts or track the retry operation's metadata to report accurate progress.

[olavloite]

Nice feature. When DDL execution fails due to a missing sequence kind, the driver automatically runs ALTER DATABASE to set the default sequence kind and retries the remaining statements.

However, there is a bug in the error/metadata handling: If a DDL batch of size > 1 fails, the default sequence kind is set, and the driver retries. If the retry succeeds for some statements and then fails again, the returned BatchError computes successful statement counts only from the first execution (op.Metadata()), completely ignoring the statements that succeeded during the retry. We should combine the counts or track the retry operation's metadata to report accurate progress.

Done