I was able to reproduce #1856 by replaying the "concurrent channel
updates" test with hardcoded additional delays in the database code. It
was due to a conflict between `addOrUpdateChannel` and
`updateChannelMetaTimestampColumn`. The two calls run in parallel and
the latter completed before the former, causing it to fail. Reducing
the isolation level makes the problem disappear.

We reduce the transaction isolation level from `SERIALIZABLE` to
`READ_COMMITTED`. Note that [*]:

> Read Committed is the default isolation level in PostgreSQL.

I'm not sure why we were using a stricter isolation level than the
default one, since we only use very basic queries. Doc does say that:

> This behavior makes Read Committed mode unsuitable for commands that involve complex search conditions; however, it is just right for simpler cases

To make sure this didn't cause regression withe the locking
mechanism, I wrote an additional test specifically on the `withLock`
method.

Here is what the doc says on the `INSERT ON CONFLICT DO UPDATE`
statement, which we use for `addOrUpdateChannel`:

> INSERT with an ON CONFLICT DO UPDATE clause behaves similarly. In Read Committed mode, each row proposed for insertion will either insert or update. Unless there are unrelated errors, one of those two outcomes is guaranteed. If a conflict originates in another transaction whose effects are not yet visible to the INSERT, the UPDATE clause will affect that row, even though possibly no version of that row is conventionally visible to the command.

In the scenario described above, the `addOrUpdate` will update the row
which timestamp was updated in parallel by the
`updateChannelMetaTimestampColumn`, and it's exactly what we want.

Fixes #1856.

[*] https://www.postgresql.org/docs/13/transaction-iso.html