feat(conversationsStore) - cache conversations to BrowserStorage

[Antreesy]

☑️ Resolves

• Allow to store fetched conversations in BrowserStorage, and recover it instantly from cache, while waiting for a server response
• Conversations updated with patchConversations() action, which is called approx. every 30 seconds
• If conversation was deleted, it will be removed from the view with the next full fetch, with redirect to /apps/spreed/not-found

🖼️ Screenshots

🏚️ Before	🏡 After

🚧 Tasks

• Manual testing
• Code review

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not required
• 📘 API documentation in docs/ has been updated or is not required
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required
• 🔖 Capability is added or not needed

[ShGKme]

Tested, works fine. Only some naming preferences.

Checked that LS is pruned on logout, not security issues ✅

---

From the UX side: after reload, a user sees an old conversations list with old last messages. That could be confusing. Should we add any small load indicator?

---

BrowserStorage is reused by tabs. If we store conversations in the browser storage, we should do it only once.

Currently it is used only for initialization. But if we open 5 tabs with Talk, then we have 5 apps with 5 conversation re-fetchings and 5 parallel updating localStorage. The most optimal solution here could be to run re-fetching only on one tab/worker and listen to the storage windows event or BroadcastChannel.

[ShGKme]

Upd: instead of shared worker, it could be easier and better for browser support to use Web Locks API

[ShGKme]

Notes about using Web Locks API here.

We don't have actually a "resource" that we want to block. But we can use a Leader pattern.
With Locks API we can lock a tab to be a "Leader" who is responsible for everything that should be done only in one tab. Then let's call "being a leader" a resource that is lock for infinity time (until the tab is not closed).

Then we can create a helper like

async function onTalkLeaderTab(() => {
  // Promise of waiting to be a leader
  return new Promise((resolve) =>
    // Request "being a leader"
    navigator.locks.request('talk:leader', () => {
      // Since we got this "resource" this tab is a leader. Resolve promise
      resolve()
      
      // Infinity promise, resource is blocked forever, while tab is not closed
      return new Promise(() => {})
  }
}

onTalkLeaderTab()
  .then(() => {
    // Now we are the leader
    // Start the setInterval for re-fetching or anything
  })

One important thing: it only works with HTTPS ⚠️

Then we can use the BroadcastChannel to inform other tabs about new conversations (cc nextcloud-libraries/nextcloud-event-bus#600)

[ShGKme]

Tested, everything seems to work fine. Tested with 2-3 tabs, with changing leader, creating new conversations, deleting conversations.

[ShGKme]

Follow-up: because x-talk-hash header is checked not in any HTTP response, but only in re-fetching conversations for the LeftSidebar, it is not checked not in sub-tabs.

[Antreesy]

Follow-up: because x-talk-hash header is checked not in any HTTP response, but only in re-fetching conversations for the LeftSidebar, it is not checked not in sub-tabs.

Rebased, follow-up fixed with additional broadcasted message specifically for talk hash.
Also a logic has been moved to the store and App.vue, to be able to use a 'leader' locked status within different processes in one tab.

[ShGKme]

Follow-ups:

• Don't cache conversations when nothing actually changed (we know it from the patching action)
• Add methods to post specific messages into the broadcast channel into the talkBroadcastChannel service as well as methods to add message handlers
• Think about centralized way to control what and when is synced, when to post messages

[Antreesy]

/backport to stable27