Browse other conversations during a call (with a second signaling session)

[vladopol]

Browse other conversations during a call (with a second signaling session)

Fixes #12299

Summary

While a call is ongoing, the user can now navigate to and interact with other
conversations in the same window, without the call being interrupted and
without opening a second window or tab. The browsed conversation stays
live-updated — new messages arrive instantly via chat-relay and typing
indicators are shown — because it is backed by a second, lightweight signaling
session.

This supersedes the earlier single-session attempt (#18787), which was correctly
rejected for lacking the second signaling session described in the dev notes on
this issue. The approach here follows those notes directly:

• track Talk-session-scope items depending on a unique (tab) id … from here it's
  theoretically possible to send different HTTP requests from the same tab to
  different rooms
• after the ability to distinguish HTTP requests, maintain a second signaling
  (websocket) connection, maybe simplified

How it works

The primary signaling + WebRTC singleton stays pinned to the call and is
never touched. For the conversation being browsed, a separate, lightweight
signaling connection is opened that:

• Runs on a second Talk session in the same tab. The tab-id request header
  (x-nextcloud-talk-session-tab-id, feat(sessions): Allow multiple Talk session in the same conversation with the same PHP session #17230) is now applied non-destructively,
  and browse requests carry a dedicated secondary tab-id, so the server maps
  them to a distinct session (TalkSession keys sessions by tab-id) instead of
  the one holding the call.
• Never joins a call and never sets up WebRTC/media — it only handles
  chat-relay (instant messages) and typing.
• Does not leak its events onto the global EventBus. A per-instance
  allow-list forwards only supportedFeatures; the token-scoped chat-relay
  message events flow as usual, so the call state is never affected.

Lifecycle: the secondary session is mounted when navigating to another
conversation during a call, switched when browsing further, and torn down when
returning to the call's conversation or when the call ends.

On the internal (non-HPB) signaling backend there is no cheap second
connection, so it transparently falls back to the previous REST/polling browsing
behaviour.

What the user sees

• The call keeps running (audio in the background) while browsing another
  conversation; returning to the call's conversation shows the call view again.
• Messages posted in the browsed conversation arrive instantly.
• The "is typing …" indicator works in the browsed conversation.

Files

• utils/webrtc/browseSignaling.js (new) — lifecycle of the secondary chat-only
  signaling session; also loads/refreshes the browsed conversation's participant
  list (needed by participant-dependent UI such as the typing indicator, which
  is not fetched the usual way while browsing).
• services/talkSessionUniqueTabId.ts — secondary tab-id + a non-clobbering
  request interceptor and a helper to route a request through the browse session.
• utils/signaling.js — optional per-instance allow-list for events forwarded to
  the global EventBus (setEventBusEmitAllowlist).
• utils/SignalingTypingHandler.js — attribute received typing to the room the
  signaling connection is joined to (identical behaviour for the primary
  connection, correct for the secondary one).
• App.vue — navigation guard that keeps the call alive while browsing, plus
  mount/switch/teardown of the browse session and teardown on call end.
• components/NewMessage/NewMessage.vue — enable the composer while browsing
  during a call.

Requirements

Live updates for the browsed conversation require the High-Performance Backend
and multiple Talk sessions per device (#17230). Without them, browsing falls back
to REST/polling.

Trade-offs

Only one browsed conversation is kept live at a time (the one currently viewed),
which keeps the second connection cheap — in line with the "maybe simplified"
note.

Testing

• Manual, Talk Desktop client against a production server: start a call in
  conversation A, browse conversation B — the call is not interrupted; a message
  and typing from another participant in B appear live; returning to A the call
  is intact; ending the call while browsing tears the session down. The server
  shows two distinct Talk sessions (call + browse) and a single call session.
• Unit tests added for the secondary tab-id helper and the EventBus
  allow-list.
• Full lint, stylelint, ts:check and unit suite pass.