sa: truncate times in type converter

[jsha]

We believe the MariaDB query planner generates inefficient query plans when a time index is queried using high precision (nanosecond) times. This uses the updated borp from letsencrypt/borp#11 to automatically truncate time.Time and *time.Time in query parameters.

Part of #5437

[jsha]

BTW thanks to @aarongable and @beautifulentropy for encouraging me to find a more systemic fix in #7519 (review).

I did a version of this change where instead of truncating, it would panic if it received an untruncated time. It found a couple of call sites that I missed in #7519 which are probably pretty important to performance (SELECTs against time indexes that are called on new-order):

boulder/sa/rate_limits.go

Lines 75 to 77 in 8545ea8

	"earliest": timeRange.Earliest.AsTime(),
	"latest": latest,
	})

boulder/sa/rate_limits.go

Lines 131 to 133 in 8545ea8

	"earliest": req.Range.Earliest.AsTime(),
	"latest": req.Range.Latest.AsTime(),
	},

[jsha]

Also, once this change lands I'll submit a separate revert of #7519.

[pgporada]

Looks good to me, but I have a borp question.

Do queries wrapped in a (t *Transaction) get unwrapped for lack of a better term into their underlying (m *DbMap) so that both transactional and non-transactional queries run through m.convertArgs?

[aarongable]

Do queries wrapped in a (t *Transaction) get unwrapped for lack of a better term into their underlying (m *DbMap) so that both transactional and non-transactional queries run through m.convertArgs?

We create transactions using DbMap.BeginTx, which contains the original dbmap as a struct member and passes it into a set of helper functions which end up calling the methods (like QueryContext) which now do the transformation.