Allow notification batching

[roznawsk]

Description

• Goal: send multiple notifications per wire frame without breaking peers built
  against the old schema.

Considered alternatives

• Dedicated Notification message inside ServerMessage as oneof option: structurally rules out
  recursion, but every new notification has to be added in two places with
  matching tags — too costly to maintain.
• Top-level ServerMessageBatch sibling of ServerMessage: structural
  non-recursion for free, but forces the receiving side to know which message type is being received at the moment

Trade-off accepted: schema permits a batch-of-batches; doc comment forbids it.
Reuse of ServerMessage keeps future notifications a one-line addition.

Motivation and Context

Why is this change required? What problem does it solve? If it fixes an open
issue, please link to the issue here.

Documentation impact

• Documentation update required
• Documentation updated in another PR
• No documentation update required

[linear]

FCE-3247 Add batching to server notifications

[Copilot]

Pull request overview

Adds protocol support for batching multiple ServerMessage notifications into a single wire frame while aiming to remain backward-compatible with peers that don’t support batching.

Changes:

• Introduces ServerMessage.NotificationBatch and a new notification_batch variant in ServerMessage.content oneof.
• Updates generated Elixir protobuf module to include the new message/oneof variant (and adds an opt-in flag in AuthRequest).
• Updates generated protocol documentation (doc/docs.md) to document the new batch message/variant.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
fishjam_protos/lib/fishjam/server_notifications.pb.ex	Adds generated Elixir definitions for NotificationBatch and notification_batch (also adds supports_notification_batch to AuthRequest).
fishjam/server_notifications.proto	Defines ServerMessage.NotificationBatch and exposes it in the ServerMessage oneof as notification_batch = 33.
doc/docs.md	Documents ServerMessage.NotificationBatch and adds it to the ServerMessage oneof table and ToC.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Critteros]

Curious if all notifications will be batched after this change? @roznawsk

[roznawsk]

@Critteros
There will be new Room / Stream config added in Fishjam API. If batchWebhookNotifiactionsis set to true, all notifications except Vad will be batched.

[Critteros]

@Critteros There will be new Room / Stream config added in Fishjam API. If batchWebhookNotifiactionsis set to true, all notifications except Vad will be batched.

What would be the interval between batches? Some of the received notifications might require immediate dispatch like RoomCrashed, RoomDeleted, other like PeerAdded, PeerDeleted, TrackMetadataUpdated need smelter composition update and the maximum acceptable latency between event occurring and its dispatch should be at most 1-2 seconds, will the batching solution be compatibile with it?

[roznawsk]

As the first iteration we could not introduce any interval. In such case, the interval would be the time to send single webhook. We would send all queued notifications for the given room/stream, wait for the request to complete, repeat 🔁

[Critteros]

As the first iteration we could not introduce any interval. In such case, the interval would be the time to send single webhook. We would send all queued notifications for the given room/stream, wait for the request to complete, repeat 🔁

Sounds good, this should also have an positive impact on the overall latency as queue will be emptied faster