Implement IndexedDB listeners logic so that it can be used independently of Vuex

To allow UI updates to be propagated to other browser tabs, we currently use our custom IndexedDB Vuex plugin:

https://github.com/learningequality/studio/blob/412f26fc109a2bdc7a9ef8544617a7fc3f8c625f/contentcuration/contentcuration/frontend/shared/vuex/indexedDBPlugin/index.js#L1-L129

Together with related logic in the Vuex store factory:

https://github.com/learningequality/studio/blob/412f26fc109a2bdc7a9ef8544617a7fc3f8c625f/contentcuration/contentcuration/frontend/shared/vuex/baseStore.js#L1-L81

this plugin ensures that whenever data are updated in an IndexedDB table from one browser tab, they will be propagated to other browser tabs by calling a related Vuex mutation that will update Vuex state which will then reactively propagate to components. Vuex mutations are registered in Vuex modules in listeners property. For example:

https://github.com/learningequality/studio/blob/412f26fc109a2bdc7a9ef8544617a7fc3f8c625f/contentcuration/contentcuration/frontend/channelEdit/vuex/contentNode/index.js#L64-L69

says that whenever an item of the IndexedDB content node table is created/updated/deleted then ADD_CONTENTNODE/REMOVE_CONTENTNODE mutations will be committed.

These mutations will be commited in all browser tabs except the tab that caused the IndexedDB table update:

https://github.com/learningequality/studio/blob/412f26fc109a2bdc7a9ef8544617a7fc3f8c625f/contentcuration/contentcuration/frontend/shared/vuex/indexedDBPlugin/index.js#L113-L114

As we're moving away from using global Vuex state towards more local states (e.g. in-component state, composable state), we need to have this logic available for use outside of the Vuex context.

For example, to be able to resolve https://github.com/learningequality/studio/issues/3447 while maintaining browser multi-tab synchronization, we'll need to listen to IndexedDB content node table updates and propagate them to a new state that will no more live in Vuex.

The goal of this issue is to prepare this IndexedDB listeners logic so that it can be used flexibly from components data, composable functions, etc.

Background

• We accumulate content nodes data in Vuex contentNode/state from various Studio features of the channelEdit app and there is no mechanism for clearing them which causes memory leaks. This issue is part of a larger group of issues (see https://github.com/learningequality/studio/issues/3363) that aim to refactor problematic features away from using Vuex global state towards private in-components state or state that’s shared between more components but is cleared at some point and optimized performance-wise in general.
• Ultimately, we want to get rid of globally stored content nodes data completely, however, this will be implemented incrementally, and therefore it’s fine to use mixed sources of data in the transition stage as long as all features continue working well from the user-point of view. Using composables is not required in all cases but is recommended as it has proven to be useful for state management across our products and it is flexible enough to allow us to keep using Vuex partially during the transition stage.

Acceptance criteria

• A logic similar to the IndexedDB Vuex plugin can be used from components and composables and it has no dependencies on Vuex
• Similarly to how our current Vuex IndexedDB plugin works, the new logic shouldn't invoke a listener handler in a tab that originated an IndexedDB table update
• Our current IndexedDB plugin stays functional
• Before merging, we are certain that the new implementation can be successfully used from at least one issue from the list of issues above that are blocked by this issue

Notes

• Because of the last acceptance criteria, it may make sense to work on this issue together with one simpler issues from "Stop using Vuex global content nodes state" group, for example https://github.com/learningequality/studio/issues/3447. We can then fulfill this acceptance criterion by ensuring that updates of a newly implemented local state are propagated to all browser tabs.
• You can see Frontend data handling and Data flow diagram for high-level overview of frontend data flow

Blocking

• https://github.com/learningequality/studio/issues/3437
• https://github.com/learningequality/studio/issues/3446
• https://github.com/learningequality/studio/issues/3447
• https://github.com/learningequality/studio/issues/3451
• https://github.com/learningequality/studio/issues/3452
• https://github.com/learningequality/studio/issues/3453
• https://github.com/learningequality/studio/issues/3458
• https://github.com/learningequality/studio/issues/3459
• https://github.com/learningequality/studio/issues/3462
• https://github.com/learningequality/studio/issues/3463
• https://github.com/learningequality/studio/issues/3466

Start with frontend/shared/vuex/indexedDBPlugin/index.js and frontend/shared/vuex/baseStore.js, then inspect the contentNode Vuex module's listeners in frontend/channelEdit/vuex/contentNode/index.js. Compare the existing listener flow with issue 3447 and the frontend data-handling documentation. Done means Vuex-independent listeners can be used by components or composables, skip the originating tab, and leave the current plugin functional.