Require SQLite >= 3.27.0

[DMRobertson]

As per #12983 (comment): bump the min version, then remove can_native_upsert.

[erikjohnston]

🎉

[DMRobertson]

I think this comment is now a bit out of date:

synapse/synapse/storage/database.py

Lines 1136 to 1144 in f2d2481

	`lock` should generally be set to True (the default), but can be set
	to False if either of the following are true:
	1. there is a UNIQUE INDEX on the key columns. In this case a conflict
	will cause an IntegrityError in which case this function will retry
	the update.
	2. we somehow know that we are the only thread which will be updating
	this table.
	As an additional note, this parameter only matters for old SQLite versions
	because we will use native upserts otherwise.

Is this update correct?:

Historically we could not assume that Synapse's database supported upsert
statements. On platforms without upserts, we emulated these with a SELECT
followed by either an INSERT or UPDATE. If the emulated upsert races with
another INSERT operation then we could end up adding two rows instead of 
one, which would be A Bad Thing. On platforms with native upserts this race
is not possible.

The race can be avoided in several ways.
1. If there is a UNIQUE INDEX on the key columns. In this case a conflict
    will cause an IntegrityError in which case this function will retry
    the update.
2. We might know that a race is impossible because we are the only thread
    or worker which will be updating this table.
3. Failing that we lock the entire table so that nothing may change it during the
    emulated upsert's transaction.

Nowadays Synapse's databases all support upserts. But it may sometimes be
unsafe to upsert because [...]. In this case, `lock` should be set to `True` unless
you can guarantee that either condition 1 or 2 holds.

What I don't understand is the [...]. Are there any conditions now in which
it is unsafe to upsert into a database? I.e. can we completely remove the
emulated upserts now?

[richvdh]

Are there any conditions now in which
it is unsafe to upsert into a database? I.e. can we completely remove the
emulated upserts now?

For a native upsert to work correctly, you need a unique index on the "key" columns for the upsert. There exist tables (those listed in UNIQUE_INDEX_BACKGROUND_UPDATES) which we would like to upsert to, but whose unique indexes were created only as background updates. It is therefore possible, if unlikely, that the aforementioned background updates have not yet run and it is therefore unsafe to perform a native upsert.

But yes, the comment is out of date.