LG-12294: Send single aggregated email notification for new device sign-in

[aduth]

🎫 Ticket

LG-12294

🛠 Summary of changes

Implements the dispatching of a new aggregated email notification for sign-in, which happens 5 minutes after successful email and password submission, or immediately upon successful MFA, whichever occurs first.

This builds upon ("wires up") previous work in #10314 (email template) and #10317 (worker for delayed notification).

📜 Testing Plan

Verify that you are sent an email immediately upon full authentication:

1. In a private browsing session ("Incognito"), visit http://localhost:3000
2. Sign in with email and password
3. Complete MFA step
4. Observe you see an email notification immediately with listed events
   • Note that it's likely to show "unknown location" since events save '::1' as the IP address in local development

Verify that you are sent an email after delay upon partial authentication:

1. Optional: Change configured delay and/or worker frequency to avoid having to wait a full 5 minutes:
   • Set new_device_alert_delay_in_minutes: 1 in config/application.yml (changes notification to send after 1 minute instead of after 5 minutes)
   • Set cron_5m in job_configurations.rb to '0/1 * * * *' (changes jobs to run every 1 minute instead of every 5 minutes)
2. In a private browsing session ("Incognito"), visit http://localhost:3000
3. Sign in with email and password
4. Wait until the next worker run after the delay specified in configuration
5. Observe you see an email notification with listed events
   • Note that it's likely to show "unknown location" since events save '::1' as the IP address in local development

👀 Screenshots

Partial Authentication	Full Authentication

[kevinsmaster5]

I see this method returns true and satisfies the emails_sent increment 👍

[kevinsmaster5]

is the workflow different here than in
https://github.com/18F/identity-idp/pull/10370/files#diff-e3f99660c095fef2341988d158c40d0a47ab706abf98070b32cb4a7ce4b02b71R19-R21

[aduth]

Yeah, the other code path accounts for a user signing in using their PIV ("Sign in with your government employee ID" on the Sign In page). In that flow, they never submit their email and password, so we don't get that sign_in_new_device_at assigned.

[kevinsmaster5]

LGTM 👍

[aduth]

I did a final round of testing here before merge, and pushed a minor content change and additional test case. Specifically, I tested an edge case where someone submits their username and password, is delayed in finishing the MFA step long enough to trigger the email notification, but eventually finishes MFA.

This works as expected insofar as it sends two emails, one for the initial delay, and another for the final authentication. This benefits from the same alternative codepath discussed in #10370 (comment) .

0aa2d49 adds feature test coverage for this scenario.

6259d16 improves content to avoid a weird "failed to authenticate 0 times" if the user never MFAs. I also noticed a period was missing, fixed in 27e8f72.

Before	After