Add support for DB migrations

[S7evinK]

This doesn't magically resolve performance issues just yet, as we are still hitting the database quite often to do updates.
Setting a fillfactor may reduce the load on the database, since the indexes possibly don't need to be updated, if there is still space in the block. (For reference - https://www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance/)

As for the claim that DeepEqual uses fewer allocations, benchmark results from my machine:

$ POSTGRES_DB=syncv3_test go test -bench=. -count 5 -run=^# -benchmem
goos: linux
goarch: amd64
pkg: github.com/matrix-org/sliding-sync/state
cpu: 12th Gen Intel(R) Core(TM) i5-12500H
BenchmarkReflectDeepEqual-16            13089988               101.9 ns/op           192 B/op          2 allocs/op
BenchmarkReflectDeepEqual-16            11241507                97.74 ns/op          192 B/op          2 allocs/op
BenchmarkReflectDeepEqual-16            12605713                97.81 ns/op          192 B/op          2 allocs/op
BenchmarkReflectDeepEqual-16            11592146               104.6 ns/op           192 B/op          2 allocs/op
BenchmarkReflectDeepEqual-16            11399110               101.0 ns/op           192 B/op          2 allocs/op
BenchmarkJSONMarhsalBytesEqual-16         866895              1161 ns/op             928 B/op         20 allocs/op
BenchmarkJSONMarhsalBytesEqual-16         975664              1180 ns/op             928 B/op         20 allocs/op
BenchmarkJSONMarhsalBytesEqual-16        1000000              1182 ns/op             928 B/op         20 allocs/op
BenchmarkJSONMarhsalBytesEqual-16        1000000              1192 ns/op             928 B/op         20 allocs/op
BenchmarkJSONMarhsalBytesEqual-16        1024558              1137 ns/op             928 B/op         20 allocs/op
PASS

This PR also embeds https://github.com/pressly/goose into the syncv3 binary, allowing automatic database migrations (solving #229)
New migrations can be created using

$ syncv3 migrate create $migrationName sql
$ syncv3 migrate create $migrationName go

SQL migrations work out of the box, go migrations, once the first is added, need to import _ "github.com/matrix-org/sliding-sync/state/migrations" in v3.go.

the migrate command has all the sub-commands mentioned on the README of goose.

[kegsay]

We need migration tests like what we do with dendrite. For now it will suffice to just use the v0.99.4 tag and then the checkout, to make sure things start up fine.

[kegsay]

Need to document usage in README or somewhere.

[kegsay]

I thought we were going to use JSONB to stop shuttling across MBs of data every time?

[S7evinK]

Looks like we can only reduce the data we send when swapping the device lists?

[kegsay]

Swapping or appending surely?

[kegsay]

Looks great, thank you!

[kegsay]

We should probably run this in CI too, but I won't block this PR on it.

[kegsay]

Please land this PR and do any further changes in a different PR.

[kegsay]

I didn't envisage this. I thought we'd do something more like:

if dd.OTKCounts != nil {
    txn.Exec(`UPDATE syncv3_device_data SET json_set(data, {otk}, $1) WHERE user_id = $2 AND device_id = $3`, dd.OTKCounts, userID, deviceID)
}

...and so on.

[S7evinK]

The only problem with this is, that we are hitting the database for every change in dd. So if we have changes to OTKCounts and FallbackKeyTypes, we'd hit the DB twice, instead of once. One more hit to change the DeviceLists.

Going to have a look at how we can possibly avoid the SELECT first. (but in a different PR)