Exclude alert effectiveEndDate from compare hash

[binh-dam-ibigroup]

Checklist

• Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
• Any modified or new methods or classes have helpful JavaDoc and code is thoroughly commented
• The description lists all applicable issues this PR seeks to resolve
• [na] The description lists any configuration setting(s) that differ from the default settings
• All tests and CI builds passing

Description

This PR changes the alert comparison hash so that two alerts with the same header, text, url, start date, but different end dates, are considered the same for notification purposes. This allows an alert that has an effectiveEndDate "extended" from one run of CheckMonitoredTrip to the next to not be unnecessarily treated as a new alert resulting in new notifications every minute.

The question becomes, should a full comparison hash that includes effectiveEndDate be kept for other uses?

To test/reproduce the issue locally using the dev branch:

1. From the OTP UI, save a trip departing within 30 minutes that contains at least one service alert.
2. Observe that an "initial reminder" notification is sent with that alert.
3. In Mongo, open the record for the saved trip and find the corresponding alert in journeyState > matchingItinerary.
4. Change the alert effectiveEndDate field to something different, then save the record for the trip.
5. Observe that a new notification is sent every minute, with the same alert appearing as both "new" and "resolved".
6. Using this branch, observe that no other notification is sent.

[amy-corson-ibigroup]

Makes a lot of sense! Thank you so much for figuring this out! One question but otherwise LGTM

[amy-corson-ibigroup]

Would we want to remove the effectiveEndDate on line 16 as well?

[binh-dam-ibigroup]

I think we still want to keep that for persistence and future processing.

[JymDyerIBI]

👍 These look good.