Disable transaction_timeout on long-running maintenance paths for PG17

What does this MR do and why?

Database Reliability is rolling out a cluster-wide 30 minute transaction_timeout (PostgreSQL 17+) on the gprd and gstg Patroni clusters as the corrective action for gitlab-com/gl-infra/production#18677 (closed).

Web, Sidekiq and migrations all connect as the same gitlab role, so the maintenance paths that legitimately run for longer than 30 minutes cannot be exempted at the database level. They already lift statement_timeout or idle_in_transaction_session_timeout in code. This MR handles transaction_timeout in the same window through a small Gitlab::Database::TransactionTimeout helper that is a no-op before PostgreSQL 17, where the setting does not exist. Paths that set statement_timeout = 0 disable transaction_timeout too. Paths that raise statement_timeout to a bounded value (reindexing, async index creation, async constraint validation, partition analyze) set transaction_timeout to that same value, so the caller's bound still applies to the whole transaction.

Two PostgreSQL details shape the helper. Inside an open transaction the running timer is only disarmed by a zero, so raising the value alone leaves the original deadline in place even though SHOW reports the new one; the helper issues a zero before any raise while a transaction is open. And a RESET inside a transaction restores the cluster limit and re-arms the timer, so the migration helper never resets an exemption an outer scope established, the same nesting rule it already applies to statement_timeout.

Without this, reindexing, async index creation, async constraint validation, partition management, sequence sync, table truncation, migrations and backups would be cancelled at 30 minutes once the cluster setting is enabled. This is step 3 of the rollout plan and must be deployed before the setting goes on gstg.

References

• Tracking issue: #628889 (closed)
• Rollout plan and inventory: gitlab-com/gl-infra/production-engineering#25884 (comment 3816342900)

Database review

No migrations and no application queries change. The MR only adds SET, SET LOCAL and RESET statements for transaction_timeout next to the existing ones for the other two timeouts, so there are no query plans to include.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #628889 (closed)