chore: hibernate_after in many places

[thecristen]

From debugging our application locally over the past week, I found that

• most of our memory usage is tied up in processes (this is almost true for prod metrics too, but there we have even more memory attributed to our usage of ETS)
• many processes maintain a pretty large heap size.

From the GenServer documentation:

Hibernating a GenServer causes garbage collection and leaves a continuous heap that minimises the memory used by the process.

Hibernating should not be used aggressively as too much time could be spent garbage collecting, which would delay the processing of incoming messages. Normally it should only be used when you are not expecting new messages to immediately arrive and minimising the memory of the process is shown to be beneficial.

So in this branch I explored using this strategically.

• the alerts-fetching processes were already using :hibernate (except after initializing, which I've added here), so I figured it's ok to have the SystemStatus caches, which rely on alerts, to use these too
• ServiceDateRollover is a ~once a day thing, so I added :hibernate after that message,
• for a few other places: :hibernate_after will hibernate after a given amount of milliseconds without messages. This felt appropriate in most cases, because most of our GenServers have sporadic activity

Some slightly more involved tweaks here:

• fixup(SystemStatus.SubwayCache): remove state - since we already have the status saved in the ETS table, it didn't make sense to also save it in the GenServer state
• fixup(Vehicles.Repo): remove table from state - similar story here, but kept a reference to the table name

Results

Alas, what do the :observer load charts say. The lower left charts depict memory usage pretty soon after application startup.

Before	After

There's a noticeable reduction in the baseline memory usage here.

[lvachon1]

Everything looks good and works well on my end.