cleanup: Add more alert factories for use in SystemStatus.SubwayTests

[joshlarson]

Follow-up to:

• feat: Create a data structure to populate the system status widget #2330

[thecristen]

suggestion: If you adjust this function to be its own factory, you wouldn't need to create an alert and pass it to for_route/2. Say you want to call build(:alert_with_route, %{route_id: "Blue"}), that could work with something like this....

def alert_with_route_factory(%{route_id: route_id} = attrs) do
   informed_entity = InformedEntitySet.build(:informed_entity_set,
      route: route_id,
      entities: InformedEntity.build_list(1, :informed_entity, route: route_id)
    )
   build(:alert, informed_entity: informed_entity)
end

[thecristen]

It'd be nice to not have to duplicate this from its source of truth.

[joshlarson]

Yeah.... What IS its source of truth?

Also I just realized this point might be moot, since SystemStatus.Subway.subway_status/2 doesn't actually do anything with the effect now. 🤔

[thecristen]

Wait, what is giving the subway status feature the "high priority" alerts then?? 😅

[joshlarson]

In alerts.ex, the filter_relevant/1 function ensures that only certain alerts are returned, and which effects are "relevant" is defined here.

In this PR, the results from alerts.ex are passed into subway_status/2.

That's how it works now - I'm not overly attached to that thought - there's probably a better way.

[thecristen]

Ah okay! In that case, the link behind "here" is the source of truth I'm referring to.

If there were a function there that exposes that list, say Dotcom.SystemStatus.Alerts.relevant_effects(), you could call that in this module where needed.