Remove password strength meter component

[aduth]

This pull request seeks to remove the Password Strength Meter component, but primarily exists to prompt a discussion around how to decrease the size of the JavaScript we publish. (In other words, I'm not attached to the idea of actually removing the component)

The password strength meter component inflates the size of the bundled JavaScript. It's the difference of 76.3kb excluded vs. 898.2kb included (12x increase). This is due to its use of the underlying zxcvbn dependency.

This size inflation is seen on most login.gov public-facing sites, including the brochure site and the IDP. This cost has incurred a high cost in effort spent toward workarounds for the large size (LG-3995, LG-3716).

The JavaScript implementation published in the design system is also not currently used in any login.gov projects. This includes identity-idp for which it was presumably intended. The IDP implements a copy of the component JavaScript (source), perhaps due to the need for internationalization of labels which the design system variant does not support. It has also fallen out-of-sync with the design system.

Some options for mitigating this could include...

1. Remove the component from the design system and consider it a custom component of identity-idp
2. Exclude the component from the "auto" version of the JavaScript bundle (including main.js), where a consuming project must opt-in to use the component
3. Exclude the zxcvbn dependency from the design system, where a consuming project must provide this themselves (e.g. by window.zxcvbn global)
4. Use dynamic import to load the zxcvbn on-demand, and only when the component is being initialized if a password meter element is present on the page
   • To a more general point, and given the recent increase in number of components we / USWDS ships by default, it could be worth exploring a pattern for loading dependencies on-demand only when component elements are present on the page
   • This imposes some requirements on how the project is consumed in order to take advantage of the optimization, since it relies on bundlers to manage code splitting e.g. Webpack, Rollup, Parcel, Browserify (?).

[zachmargolis]

The plan would be to copy this component back into the IDP and just use it there right?

Since we only use the component in the one place I am in favor of removing it from this repo to size things down, and punting the question about dynamic loading entirely

[zachmargolis]

LGTM

[aduth]

The plan would be to copy this component back into the IDP and just use it there right?

Yeah, and since we already duplicate the JavaScript, we'd only need to copy over styles.

[aduth]

I raised this during yesterday's UX Huddle, and there was general consensus that it's reasonable to remove this component for now, given that it's not currently consumed directly anywhere, and consistent with similar decisions in the past to find patterns of reuse for promoting components into the design system.