Understand & improve ActionCable memory utilization

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

As documented in &3056, we are in the process of adding ActionCable to our rails stack. Some early figures seem to suggest that this had a significant impact on per-process memory use. We also pay this cost for every instance currently, even those that do not act as an ActionCable server, since even ordinary web nodes require access to the ActionCable API to e.g. publish messages.

UPDATE: These concerns did not materialize and were conjecture based on misleading memory reports printed by PumaWorkerKiller. As the comments show, the memory impact is much smaller than first assumed.

Goals/deliverables:

• A more in-depth analysis of ActionCable's impact on memory use, broken down into:
  • Total RSS consumed [after app boot|with clients connected] for main ActionCable server
  • Total RSS consumed [after app boot|with clients connected] for normal web server
  • Explanation for the reported difference between the two types of servers, despite both pulling in the same gem (action_cable/engine)
  • Memory consumption within the ActionCable gem/engine, e.g. broken down by class or module/namespace/file

Won't do based on latest findings (see comments):

• Identifying opportunities for reducing memory cost incurred by ActionCable (for instance: server code is only relevant for an ActionCable server, not for normal web nodes; they merely publish events)
• Addressing any low-hanging fruit or breaking out new issues with proposals for how to reduce the ActionCable footprint (if possible)