borp/sa: Update borp to pass Transaction args through BoulderTypeConverter

[beautifulentropy]

Today, timestamp truncation happens for queries using *borp.DbMap but not *borp.Transaction. That means comparisons still see sub-seconds, but inserts into MariaDB DATETIME columns silently truncate them to whole seconds.

On MySQL 8, the same queries will still include sub-seconds, but inserts into DATETIME columns will round to the nearest second instead of truncate. This leads to issues for queries like the one in *StorageAuthority.UpdateCRLShard(). When two CRL updaters write within the same second one may be rounded up to the next second. When the other updater attempts its own UPDATE .. WHERE thisUpdate <= ?, the condition fails because the stored timestamp now appears to be in the future.

Ahead of the transition from ProxySQL + MariaDB to Vitess + MySQL 8 in #8468, update borp (letsencrypt/borp#12) to expose Transaction arguments to the BoulderTypeConverter, allowing it to truncate all timestamps passed through Transactions and keep behavior consistent across *borp.DbMap and *borp.Transaction, as well as MariaDB and MySQL 8.

Part of #7736

---

Example of truncation vs rounding behavior in MariaDB and MySQL 8, respectively:

MariaDB> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected, 1 warning (0.004 sec)

MariaDB> CREATE TABLE t1 (
    ->   id INT AUTO_INCREMENT PRIMARY KEY,
    ->   ts DATETIME(0)
    -> );
Query OK, 0 rows affected (0.003 sec)

MariaDB> INSERT INTO t1 (ts) VALUES
    ->   (‘2025-01-01 12:00:00.001’),
    ->   (‘2025-01-01 12:00:00.499’),
    ->   (‘2025-01-01 12:00:00.500’),
    ->   (‘2025-01-01 12:00:00.501’),
    ->   (‘2025-01-01 12:00:00.900’);
Query OK, 5 rows affected (0.000 sec)
Records: 5  Duplicates: 0  Warnings: 0

MariaDB> SELECT id, ts FROM t1 ORDER BY id;
+----+---------------------+
| id | ts                  |
+----+---------------------+
|  1 | 2025-01-01 12:00:00 |
|  2 | 2025-01-01 12:00:00 |
|  3 | 2025-01-01 12:00:00 |
|  4 | 2025-01-01 12:00:00 |
|  5 | 2025-01-01 12:00:00 |
+----+---------------------+
5 rows in set (0.001 sec)

mysql> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> CREATE TABLE t1 (
    ->   id INT AUTO_INCREMENT PRIMARY KEY,
    ->   ts DATETIME(0)
    -> );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t1 (ts) VALUES
    ->   (‘2025-01-01 12:00:00.001’),
    ->   (‘2025-01-01 12:00:00.499’),
    ->   (‘2025-01-01 12:00:00.500’),
    ->   (‘2025-01-01 12:00:00.501’),
    ->   (‘2025-01-01 12:00:00.900’);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> SELECT id, ts FROM t1 ORDER BY id;
+----+---------------------+
| id | ts                  |
+----+---------------------+
|  1 | 2025-01-01 12:00:00 |
|  2 | 2025-01-01 12:00:00 |
|  3 | 2025-01-01 12:00:01 |
|  4 | 2025-01-01 12:00:01 |
|  5 | 2025-01-01 12:00:01 |
+----+---------------------+
5 rows in set (0.00 sec)