Basic bindings to the recently implemented pgo_notifications.

[foxfriends]

Added support for PostgreSQL LISTEN/NOTIFY by lightly wrapping the implementation in pgo.

As in pgo:

• The notifications listener is started as a new process, different from a regular connection.
• The listen(conn, channel) function subscribes to a Postgres channel.
• unlisten(conn, reference) can be used to unsubscribe.
• Notifications from Postgres are sent to the process that called listen as the Notify type. Receive these using the pog.notification_selector().

General usage example:

let assert Ok(db) = pog.default_config("db")
    |> pog.start()

let assert Ok(notifications) = pog.default_config("notifications")
    |> pog.start_notifications()

let assert Ok(reference) = pog.listen(notifications.data, "some_channel")

let selector = pog.notification_selector()

let assert Ok(_) = pog.query("NOTIFY some_channel, 'some_payload'")
    |> pog.execute(db.data)

let assert Ok(Notify(pid, ref, chan, data)) = process.selector_receive(selector, 100)
assert pid == notifications.pid
assert ref == reference
assert chan == "some_channel"
assert data = "some_payload"

pog.unlisten(notifications.data, reference)

Closes #13

[foxfriends]

erleans/pgo#119

I found and patched a bug in the underlying pgo implementation, so I suggest waiting until that's merged before considering accepting this PR.

Having been trying out my patch for a few days in a project, I am finding it to work fine, but maybe is not the most idiomatic Gleam; pretty new to it all, and not sure the best way to represent this system, I went with a "light" approach so far, mimicking the pgo interface, but open to suggestions to make it more "Gleam" flavoured for sure. :)

[lpil]

Thank you! I've left some questions inline

[foxfriends]

Thanks for the notes, I have updated it, let me know if anything else :)

[renatillas]

Hello @foxfriends! While integrating notification sessions under supervision, I found two lifecycle edges:

• pgo_notifications:listen/2 may return {eventually, Ref} during reconnection, while the PR handles only {ok, Ref}

• and the notification process traps and ignores linked shutdown exits, so supervisor teardown times out unless we call gen_statem:stop(Pid, shutdown, Timeout) directly.

Would it make sense to normalize {eventually, Ref} and expose a graceful notification-session stop API or supervision specification?