Use autocommit mode for single statement DB functions.

[erikjohnston]

Autocommit means that we don't wrap the functions in transactions, and instead get executed directly. Introduced in #8456. This will help:

1. reduce the number of could not serialize access due to concurrent delete errors that we see (though there are a few functions that often cause serialization errors that we don't fix here);
2. improve the DB performance, as it no longer needs to deal with the overhead of REPEATABLE READ isolation levels; and
3. improve wall clock speed of these functions, as we no longer need to send BEGIN and COMMIT to the DB.

Some notes about the differences between autocommit mode and our default REPEATABLE READ transactions:

1. Currently autocommit only applies when using PostgreSQL, and is ignored when using SQLite (due to silliness with Twisted DB classes).
2. Autocommit functions may get retried on error, which means they can get applied twice (or more) to the DB (since they are not in a transaction the previous call would not get rolled back). This means that the functions need to be idempotent (or otherwise not care about being called multiple times). Read queries, simple deletes, and updates/upserts that replace rows (rather than generating new values from existing rows) are all idempotent.
3. Autocommit functions no longer get executed in REPEATABLE READ isolation level, and so data can change queries, which is fine for single statement queries.

[richvdh]

lgtm. Does this (mostly) fix #4993?

[erikjohnston]

Annoyingly I think the majority of instances come from DB functions not covered by this PR, as they're more complicated and would require some rejigging to make safe.