Add LoginStore::list_candidates() and LoginStore::get_many()

[jo]

for checking login candidates without encryption.

Background: The Rust logins backend can trigger a Primary Password prompt on desktop during password autocomplete before a matching login has been identified. This can affect pages containing password inputs even when no matching login exists. For matching origins, PSL is needed, which we don't ship with Rust. Simplest and minimal invasive solution is to hand over the candidate logins without encrypted fields from Rust, so that desktop can continue using the same matching function in JS.

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]

Fetching all the rows for this and passing them across the FFI doesn't seem ideal, but I think it should be okay. I believe we fetch and decrypt all the logins on Android when a user views the passwords list and this can't be worse than that. Is there a long-term plan to move the logic into Rust?

This looks fine from my POV, the only thing I wasn't sure about is how to name all of this. I remember us coming up with a bunch of different naming schemes when we first introduced the login vs encrypted login split. "LoginCandidate" seems fine to me, how do you feel about it @mhammond ?

[jo]

There is no long term plan yet. The thing which makes this a little complicated is that this PSL is needed Rust side. We could provide it's interface via Foreign Trait - but still this involves handing n logins (or their origins) across FFI borders.

This is our PSL on desktop: https://searchfox.org/firefox-main/source/netwerk/dns/effective_tld_names.dat

One thing we could at least do to reduce FFI throughput is to minimize this LoginCandidate to the bare match requirements (origins, formActionOrigin, ... to be determined).