realtime: support async encode/decode for off-isolate (de)serialization

[spydon]

Background

In #1397 the realtime client gained a pluggable encode/decode codec (RealtimeEncode / RealtimeDecode), defaulting to the protocol-2.0.0 serializer. The signatures are synchronous:

• RealtimeEncode = Object Function(Map<String, dynamic>)
• RealtimeDecode = Map<String, dynamic> Function(Object)

Because they're synchronous, jsonEncode/jsonDecode of the message payload run on the main isolate. For large payloads this blocks the event loop (and can cause UI jank on Flutter), and a consumer cannot plug in a background-isolate codec such as yet_another_json_isolate (whose encode/decode are async).

Proposal

Allow asynchronous encode/decode so (de)serialization can be offloaded to a background isolate:

• Make RealtimeEncode / RealtimeDecode (or an alternative codec object) return Futures, e.g. Future<Object> Function(Map<String, dynamic>) / Future<Map<String, dynamic>> Function(Object).
• Update RealtimeClient.push to await the encode before writing to the sink, preserving send ordering.
• Update the incoming-message flow (onConnectionMessage) to handle an async decode without reordering frames.
• Keep the default synchronous serializer fast-pathed (avoid unnecessary microtask hops when no custom codec is supplied).

Notes

• This is a breaking change to the codec typedefs, so it is targeted at v3.
• Send/receive ordering is the main risk to get right when introducing awaits into the message pipeline.

Tracked for v3 (#1278).

[Vinzent03]

My current perception is that realtime events mainly consist of data per row, don't they? I suspect that realtime events are not big enough to compensate for the time and resources it takes to copy the data over to the isolate. Though spinning up the isolate takes the most time, which is already done in that case, I'm still unsure if it is worth for realtime events to offload the work.
While I think the vast majority of messages are too small to compensate for the work it takes to move the computation to a new isolate, there may be some huge rows where this is needed. Per documentation realtime allows having a payload of up to 1MB (https://supabase.com/docs/guides/realtime/limits#limits-by-plan). So I think we should add a similar size check like it is done with postgrest to use the isolate only for big payloads.

[spydon]

So I think we should add a similar size check like it is done with postgrest to use the isolate only for big payloads.

So we wouldn't create the actual isolate in here, the end user would handle that by passing in the encode and decode functions. I think now when the memory is shared between isolates it would be quite efficient for an end user to spin up a long lived isolate (with integral_isolates for example) and then just handover the messages to that.