Understand real-time issues sidebar context boundaries

Broken out of https://gitlab.com/gitlab-org/memory-team/team-tasks/-/issues/39

In order to enable real-time updates for the issue sidebar, we decided to run an ActionCable server to facilitate client-server communication between the sidebar and the backend. We are concerned about the memory footprint this will imply, since currently the ActionCable server loads the entire Rails application into memory as any ordinary web node would.

We should look for opportunities to only load those parts of the application necessary to service this particular feature.

Goals/deliverables:

• Memory breakdown of any code involved in serving sidebar updates to clients
• Identify opportunities for how this code could be isolated and loaded independently (one way of thinking about this would be: what would this look like if it was a service built purely for this feature?)