Logins: Breach Alerts

[jo]

This PR adds Breach Alert support to the Logins component by extending the Logins API and introducing breach-related metadata and queries. It includes a database migration to version 3 and provides the necessary primitives for consumers (e.g. Firefox Desktop) to record breaches, evaluate potential exposure, and track alert dismissals.

New Login properties

• time_of_last_breach
  System time in milliseconds corresponding to the breach’s BreachDate.

• time_last_breach_alert_dismissed
  System time in milliseconds indicating when the user dismissed the breach alert.

Additional LoginStore API methods

• record_breach(id, timestamp)
  Stores a known breach date for a login.
  In Firefox Desktop this is updated once per session from Remote Settings.

• reset_all_breaches()
  Removes all recorded breaches for all logins (i.e. sets time_of_last_breach to null).

• is_potentially_breached(id)
  Determines whether a login’s password is potentially breached, based on the breach date and the time of the last password change.

• record_breach_alert_dismissal(id)
  Records that the user dismissed the breach alert for a login using the current time.

• record_breach_alert_dismissal_time(id, timestamp)
  Records that the user dismissed the breach alert for a login at a specific time. This is primarily useful for testing or when syncing dismissal times from other devices. For normal usage, prefer record_breach_alert_dismissal which automatically uses the current time.

• is_breach_alert_dismissed(id)
  Determines whether a breach alert has been dismissed, based on the breach date and the alert dismissal timestamp.

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

[bendk]

Looks good to me. I had a couple suggestions, but nothing blocking. I don't need to re-review.

[bendk]

Now's probably a good time to add a schema upgrade test like the one suggest has:

application-services/components/suggest/src/schema.rs

Lines 1013 to 1018 in eea8d80

	fn test_all_upgrades() {
	let db_file =
	MigratedDatabaseFile::new(SuggestConnectionInitializer::default(), V16_SCHEMA);
	db_file.run_all_upgrades();
	db_file.assert_schema_matches_new_database();
	}

It should be fairly easy, the only real work is finding an older version of the schema to use as the base. We could just use v2 for that.

[jo]

There was already a specific schema upgrade test for version 2 (test_upgrade_v1), which I had previously only extended for the new schema, but which I have now generalized and simplified and adapted to the style of the test from Suggest.
That's a great improvement, thanks for the hint!