chore(electric, docs): Update docs to mention supported data types

[alco]

Here I'm also removing int8 from the list of types accepted by the electrify() function since it's not handled correctly on the client.

Closes VAX-1034.

[linear]

VAX-1034 Update the docs to mention supported data types

…and to explain the rationale of not supporting some types, such as timetz.

Maybe drop support for BIGINT and REAL for now?

[thruflo]

Looks great 👍

[davidmartos96]

Is int8 support something that can be fixed in the client?

We are actually using it successfully with the Dart client to send timestamps. Are they being removed because of the 2^53 limit on JS?

https://api.flutter.dev/flutter/dart-core/int-class.html

We've been storing them as integers on Sqlite, so it's a bit unfortunate that they are not supported on Electric.

[alco]

@davidmartos96 Since JavaScript numbers cannot represent all values that a true 64-bit integer can hold, this opens up a door to silent data corruption. Imagine inserting a bigint 4611686018427387904 in Postgres, syncing that to SQLite as a string-encoded value. No data loss so far. But then if the value is read into a JS number it will get rounded. If the client then writes it locally and it is synced up to the server, the silent and unintended change becomes permanent.

> Number("4611686018427387904")
4611686018427388000 

Repairing such silent corruption after the fact can be difficult or impossible.

So we want to be conservative in choosing the types we allow to electrify now, until we add the necessary mapping from Postgres' bigint to JS' bigint in the TypeScript client.

The Dart client will also need to account for this. We're exploring the option of setting up a generative test suite that could be used to generate semi-random data and throw it at client-side validations. Then, whatever is validated on the client would be synced to the server to verify that the value can also be written to Postgres and that it doesn't change in the process. We should come up with a way to use the same test data with different client implementations.

[davidmartos96]

Thanks for the info! A generative test suite sounds really useful to test edge cases with different client implementations.