Remove logins time_of_last_breach column

[jo]

In #7127, we added breach alerts support.

However, in further discussions, we came to the conclusion that the column time_of_last_breach is not directly necessary, as this information can also be pulled from the Remote Settings during runtime. Performance optimizations should be subordinate to the principle of data spareness.

Therefore, this PR removes the time_of_last_breach column introduced in #7127, along with their accessors. Since this column is not yet used in Mobile, no data migration is necessary.

BREAKING CHANGES

• Removed time_of_last_breach field from LoginMeta and Login. This can be derived from Remote Settings during runtime instead.

• Removed record_breach(id, timestamp) API method.

• Removed is_potentially_breached(id) API method.

• Removed is_breach_alert_dismissed(id) API method.

• reset_all_breaches() now clears the breachesL password table instead of resetting time_of_last_breach timestamps.

• Schema migrated to version 5: timeOfLastBreach column dropped from loginsL and loginsM.

The Phab Patch to adapt LoginsStorage.kt and Types.kt: https://phabricator.services.mozilla.com/D285208

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]

This looks right to me and the plan outlined makes sense.

What's happening with record_potentially_vulnerable_passwords? Is that still needed if you're getting the breach data from remote settings?

[jo]

What's happening with record_potentially_vulnerable_passwords? Is that still needed if you're getting the breach data from remote settings?

Yes, this is still needed, same with last_time_breach_alert_dismissed.