Add ability to support importing passwords from Google as CSV

[CDRussell]

Task/Issue URL: https://app.asana.com/0/608920331025315/1207415218447811/f

Description

Adds ability to import passwords exported as a CSV from Google Password Manager (GPM). This functionality is used by the higher up branches in the stack to provide a guided way to import from GPM, but can be tested directly from autofill dev settings and choosing to import a CSV file.

Test CSV files are available in Example CSV files for testing

Steps to test this PR

Happy path: all unique

• Fresh install internal build type, and launch autofill dev settings
• Choose Import CSV
• Choose CSV file containing only unique entries and verify all are imported (e.g., choose example_csv_20.csv and make sure 20 are imported)

Happy path: importing with some duplicates in the list

• Delete all saved credentials
• Choose Import CSV again, and this time choose file containing duplicates
• verify correct amount imported (e.g., choose dupes_20_total_17_unique.csv and make sure 17 are imported)

Happy path: importing with a duplicate already saved in the DB

• Add a credential that matches what is in the CSV you will export
• Import the CSV
• Verify the correct amount imported and the already-saved one wasn't duplicated

Non-CSV files

• Choose Import CSV
• Pick a file that isn't a password CSV export
• Make sure it handles this gracefully

[CDRussell]

• Add ability to support importing passwords from Google as CSV #4601 : 2 dependent PRs (#4602 , #5097 ) 👈 (View in Graphite)
• Add feature flag for importing passwords via Google Password Manager #5096
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[malmstein]

The Purge!

[cmonfortep]

I'm not sure about this one 😅. If we don't know how to normalize the input, we just return the input. But then we store it as domain attribute...but that can be anything. 🤔

You have more context than me on Autofill, but what are the side effects of not having a domain in the domain attribute? I assume we are not validating the user manually enters something valid either...so at this point, I wonder why do we even normalize, or why do we even filter the "android://..." objects...

Short term, just to consider if this is the expected behavior, and then we can chat about the class fields without blocking the changes here as it seems a more broad discussion.

[CDRussell]

This behavior mirrors what we do when saving credentials. If we can, we normalize the URLs when we encounter them, or when the user enters them manually (a product decision from way back). If the URL is unrecongizable as a URL and therefore we can't normalize it (when saving from autofill or from a user entering manually), we save it unaltered.

[CDRussell]

what are the side effects of not having a domain in the domain attribute

if it's unrecognizable, we won't be able to match on it and it won't be offered as an option in the autofill dialogs but will still be stored in the full credential list

[cmonfortep]

Works great. Let's discuss on zoom the models being used here, so I can have more clarity and decide next steps.

[cmonfortep]

Approving as I don't feel this is a blocker, but let's revisit together.