`max_statement_time` is ineffective in multiple-query scenarios

In sa/database.go, we set the SQL connection-level variable max_statement_time to tell the MySQL server to terminate queries if they are going to take longer than a configured timeout. However, this assumes that every query can take the full allotted time. In some situations, notably RA.NewCertificate, we may be making multiple RPC calls to the SA, and with each call there is less time left available before the RPC deadline. Ideally we would set max_statement_time on a per-query level based on the amount of time left to that query. However, we used to do this, and it triggered a hard-to-diagnose memory leak in MariaDB: https://jira.mariadb.org/browse/MDEV-12205.

To some extent we don't care that much whether we get a max_statement_time exceeded error vs a deadline exceeded error. However, the same code is also used to set a long_query_time, so fixing it might allow us to see the query that caused slowness in some cases.

Start in sa/database.go and trace how max_statement_time and long_query_time are applied during the multiple SA calls made by RA.NewCertificate. Review the MariaDB MDEV-12205 context before choosing a per-query approach. Done means remaining RPC time is respected without reintroducing the reported memory leak, while preserving useful long-query reporting.