performance: Move API calls out of render and into subway_status

[jlucytan]

Scope

Asana Ticket: 📈 🛠️ [Subway Status] Move API calls / stop-loading out of component-rendering

Implementation

Moves affected_stops and endpoint_stops out of status_row_heading and into subway_status so there are fewer API calls at render time on the home page, and the data is cached.

The alerts page and schedule finder still make calls to populate the subheading for the Planned Work section, however.

Although commuter_rail_upcoming_changes also utilizes the status_row_heading component, I don't believe it currently shows any subheadings, so no data is added there.

Screenshots

Should have no visual changes.

Old flamegraph:

New flamegraph:

How to test

Homepage, alerts page, schedule finder alert banners, commuter rail upcoming changes appearances should not change between this branch and prod.

[joshlarson]

I like what I see so far, and having these calls not run per-component-load is going to be a huge win!

However, I think something's gone a bit wrong with combining subheadings. Compare dev-green on the left to this branch on the right.

It looks like status on the alerts page is combining subheadings from different rows even when the rows themselves aren't being combined, but on that page, each row should only show the affected stops or endpoints from the alert associated with that row.

[joshlarson]

This looks great, and when running locally and looking at flamegraphs, I was seeing a consistent improvement of about 70ms (rendering going from ~268ms to ~198ms), which is HUGE. Plus, hand-wavy-guess it wouldn't shock me if this was also one of the more memory-consuming parts of individual page loads, which makes this even more impactful.

I left some stylistic feedback, but none of it is blocking, and can all be addressed as follow-ups, if at all.