[Tracking]: Improve mockability of the entire manager context in stories

[Sidnioulz]

Problem statement

We don't currently have an easy way to mock the manager API in our own internal stories. We tend to mock parts of the API with varying degrees of success in individual component stories as needs arise.

Besides that, some of the submodules (e.g. layout) aren't written with mockability in mind (e.g. top-level default state export that consumes global.), making it harder to mock all of the modules' logic. And submodules that read from @storybook/global are further harder to mock because changing the value of global in a story can leak to the manager UI if that story is the first one being loaded.

Having a unique, solid way to mock the manager, covering all of API methods, internal state and initialisation logic, would allow us to write stories for:

• edge cases in components that consume the API (e.g. TagsFilter when default tags are set in .storybook/main.ts) without having to transform everything the component is consuming into props (which leads to severe prop drilling in the sidebar)
• how the manager UI as a whole reacts to options set via the addons singleton (e.g. addons.setConfig({ layoutCustomisations: showToolbar() {} }), currently untested
• more robust tests showing that components call the API (e.g. current Explorer stories crash when clicking on menus)
• fewer use cases of having to retroactively mock API endpoints across stories that use a component which itself consumes the API; in other words, less corrective maintenance in our stories

We (@ndelangen & @Sidnioulz) believe whole manager mocking can be achieved if we automock specific parts of submodules that would cause runtime issues and simplify creating a manager provider in stories.

Milestones

M1: Make modules mockable

Owner: @mention
Complete by: @date

• Ensure modules do not use top-level variables for anything other than constants
• Ensure modules export individual functions that might need mocking
• Identify parts of submodules that definitely need mocking
• Set up __mocks__ folder to automock that module logic

M2: Provide a ManagerProvider decorator with a test store

Owner: @mention
Complete by: @date

• Set up a testing version of the store, that mocks persisted storage (avoids side effects & allows testing persistence in stories)
• Move store init logic outside of code/core/src/manager-api/root.tsx so we can create it with the real store or a test store
• Provide a decorator to use in stories

M3: Ensure globals are mockable

Owner: @mention
Complete by: @date

• Test vitest's stubGlobal to see if we can stub the global object as-is
• Otherwise, refactor @storybook/global to export a function rather than an object so we can easily spy on it
• Clean up stories that modify global in their beforeEach

M4: Apply decorator to relevant stories

Owner: @mention
Complete by: @date

• All components that support reading from persistent state (most of layout)
• All components that call the API (most of testing module / explorer)
• New stories for singleton config (all of layoutCustomisations)
• etc (non exhaustive)