feat: add support to realtime.messages binary payloads

[edgurgel]

What kind of change does this PR introduce?

• Add binary_payload column to realtime.messages with a constraint that only apply to new rows that checks that we can't have binary_payload AND payload NOT NULL at the same time. They can both be NULL though because we already allowed payload to be NULL so I didn't want to break anythiung. We could be more strict and ensure that one of them exclusively must be NULL.
• Add realtime.send accepting bytea overloading the existing function.

[coveralls]

Coverage is 91.265% — feat/binary-payload-realtime-messages into main. No base build found for main.

[leandrocp]

How do we handle big binaries? I can simulate a OOM crash with this payload:

payload = :binary.copy(<<0>>, 900 * 1024 * 1024)

Postgrex.query!(
  db,
  "SELECT realtime.send($1::bytea, 'oom', 'adios', true)",
  [payload]
)

Running in a container with ~1.2GB free mem

[edgurgel]

The process would reach the max heap size and crash before OOMing (The container must have a bit more memory than the max heap size we set)

realtime/rel/vm.args.eex

Line 14 in ce7bd50

+hmax <%= div(1_000_000_000, :erlang.system_info(:wordsize)) %>

[leandrocp]

Yep I was just concerned about exposing a possible scenario where one could try to send a really large bin for whatever reason.

[edgurgel]

Oh yeah makes sense! We do have this protection to not let any single process kill the system. The assumption is that we have enough free memory to not hit the limit quickly 👍