Add SQL Server (mssql2019) persistence plugin

[ashish24142]

What was changed

Adds a Microsoft SQL Server persistence plugin (mssql2019, SQL Server 2019+ / Azure SQL) that can serve both the default persistence store and the visibility store, following the existing mysql/postgresql/sqlite plugin architecture (registered via sql.RegisterPlugin, selected with pluginName: "mssql2019").

• Plugin (common/persistence/sql/sqlplugin/mssql/): per-table query implementations translated from the postgresql plugin — MERGE ... WITH (HOLDLOCK) upserts (executed per row for slices, since sqlx cannot expand MERGE), UPDLOCK/REPEATABLEREAD locking hints, TOP/OFFSET-FETCH pagination, expanded row-value tuple comparisons, central ? → @pN rebinding, passwordCommand support via RefreshingConnector, TLS-to-DSN mapping for go-mssqldb.
• Schema (schema/mssql/v2019/): all 37 main-store tables; single-table visibility (postgres layout) with PERSISTED computed search-attribute columns, a persisted coalesce_close_time ordering column, an SHA2_256 hash PK for chasm_node_maps (SQL Server's 900-byte index key limit), and full-text search over Text attributes via a row_key IDENTITY surrogate key.
• Visibility query converters: both the unified and legacy paths (OPENJSON for KeywordList, CONTAINS() for Text). T-SQL has no boolean literals, so a small optional hook (pluginBoolValueConverterLegacy) was added to the legacy converter to rewrite true/false → 1/0 for BIT columns; the unified path uses the existing ConvertComparisonExpr hook.
• Azure SQL Database compatibility: admin operations issue single-statement batches (CREATE/DROP DATABASE must be alone in a batch there), and the connection-refresh classifier includes Azure's documented transient fault codes.
• Integration: blank imports in the server and temporal-sql-tool binaries, schema.PathsByDB, AllowListForValidation, persistence test harness wiring, docker-compose service, install-schema-mssql2019 Makefile target, development-mssql.yaml.
• New dependency: github.com/microsoft/go-mssqldb v1.10.0 (registered with sqlx as "sqlserver").

Why

SQL Server is the remaining major relational database without Temporal support. Organizations standardized on the Microsoft stack (licensing, DBA tooling, compliance) currently have no supported way to run Temporal on the database they operate, on-prem or on Azure SQL.

How it was tested

All against a real SQL Server 2022 instance (Docker, with mssql-server-fts):

• Both schemas apply cleanly via temporal-sql-tool (setup-schema + update-schema).
• The server boots on mssql2019 for both stores: all shards acquired, system namespace/workflows running, no driver errors.
• End-to-end: namespace registration, workflow execution to completion, visibility ListWorkflowExecutions (including WorkflowType = '...' AND ExecutionStatus = 'Completed') and CountWorkflowExecutions return correct results.
• All 44 shared persistence CRUD suites pass — 521 subtests, 0 failures — via the new TestMSSQL entry (common/persistence/tests/mssql_test.go), covering shard, execution mutable state (+tasks), every per-table history suite, matching tasks v1/v2, task queues, queue v1/v2, nexus endpoints, metadata, cluster metadata, and the full visibility filter/count/group-by/pagination paths.
• Local load characterization (single all-in-one node, 128 shards): ~136 completed workflows/sec sustained with p95 latency ~520 ms on bare workflows.

go build ./..., go vet, and gofmt are clean across the tree.

Notes for reviewers

• Known follow-ups are marked in code comments: multi-row inserts can exceed SQL Server's 2100-parameter batch cap on very large mutations (needs chunking); KeywordList predicates use OPENJSON at query time since SQL Server cannot index inside JSON arrays.
• Happy to add a CI matrix entry (SQL Server container + mssql-server-fts) if you want this exercised in CI, and to split this PR into smaller pieces if that's easier to review.

[CLAassistant]

All committers have signed the CLA.

[ashish24142]

Note for maintainers on the failing crossrepo/saas-compatibility check: the run lives in the private saas-temporal repo, so I can't see the logs from outside. My best guess at the cause is the new dependency this PR introduces (github.com/microsoft/go-mssqldb, plus its two small golang-sql/* transitive modules), which enters the server's dependency graph the same way the other SQL drivers do — if the internal build uses a module allowlist/mirror, it won't have seen these yet. The shared-code changes outside the new plugin are additive only (an unexported optional interface in the legacy visibility converter and new switch cases), so a compile break seems less likely.

Happy to adjust whatever the internal run actually flags — and to add a public CI matrix entry for SQL Server if you'd like this exercised in this repo's CI as well.