[PM-6789] add legacy user key state

[jlf0dev]

Type of change

- [x] Bug fix
- [ ] New feature development
- [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [ ] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

When we migrated private keys to state providers, we didn't account for legacy user keys. Without being able to decrypt the private key using the legacy key (master key) we couldn't migrate the legacy users. This adds a activeUserKeyWithLegacySupport$ observable to pass in the derived state so it can correctly decrypt the private key.

Code changes

• file.ext: Description of what was changed and why

Screenshots

Before you submit

• Please add unit tests where it makes sense to do so (encouraged but not required)
• If this change requires a documentation update - notify the documentation team
• If this change has particular deployment requirements - notify the DevOps team
• Ensure that all UI additions follow WCAG AA requirements

[jlf0dev]

@MGibson1 I know we discussed moving out all the legacy code from the crypto service, but that ended up being quite the overhaul. Considering this should be the final step before removing all the legacy code, I wanted to throw this up as an option.

[codecov]

Codecov Report

Attention: Patch coverage is 60.00000% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 28.15%. Comparing base (97c7ef3) to head (7ab130a).
Report is 43 commits behind head on main.

Files	Patch %	Lines
...ibs/common/src/platform/services/crypto.service.ts	60.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9274      +/-   ##
==========================================
+ Coverage   27.91%   28.15%   +0.23%     
==========================================
  Files        2356     2369      +13     
  Lines       69622    70034     +412     
  Branches    13117    13161      +44     
==========================================
+ Hits        19435    19716     +281     
- Misses      48647    48759     +112     
- Partials     1540     1559      +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Checkmarx One – Scan Summary & Details – 357cd8e6-9269-4929-a2f1-9adcc48792c7

New Issues

Severity	Issue	Source File / Package	Checkmarx Insight
	Client_Privacy_Violation	/apps/web/src/app/billing/shared/add-credit.component.ts: 70	Attack Vector
	Client_Privacy_Violation	/apps/web/src/app/billing/shared/add-credit.component.ts: 80	Attack Vector
	Client_Privacy_Violation	/apps/web/src/app/billing/shared/add-credit.component.ts: 149	Attack Vector
	Client_Privacy_Violation	/apps/web/src/app/billing/shared/add-credit.component.ts: 138	Attack Vector
	Client_Privacy_Violation	/apps/web/src/app/billing/shared/add-credit.component.ts: 30	Attack Vector
	Client_Privacy_Violation	/apps/web/src/app/billing/shared/add-credit.component.html: 46	Attack Vector

Fixed Issues

Severity	Issue	Source File / Package
	Unpinned Actions Full Length Commit SHA	/version-bump.yml: 473
	Unpinned Actions Full Length Commit SHA	/version-bump.yml: 465
	Unpinned Actions Full Length Commit SHA	/version-bump.yml: 481
	Unpinned Actions Full Length Commit SHA	/version-bump.yml: 457

[ike-kottlowski]

Auth changes are good.

[MGibson1]

issue: please use master password service directly rather than this, which causes a weird cycle on activeUserKey$.

I would just switch map a few times from user id -> master key -> async is legacy user with a function that returns the master key again

[jlf0dev]

Fixed!

[MGibson1]

Why not just call validate -- you have all the data

What is returned if neither pass?

[jlf0dev]

1. Good point, sure why not.
2. We could return userKey (really whatever the state provider should give us if there was no userKey). The userKey nullish check should happen before we check for legacy users. So we're not doing extra computation on every request.

[justindbaur]

Heads up, I am working on some changes right now that are actually going to get rid of activeUserKey$ in favor of a method that requires a user id. If the main goal of this is that the encrypted private key needs to allow for the user of the master key for legacy reasons I can take care of that in my changes. I would need an answer to Matt's question before finishing it though.

[jlf0dev]

@justindbaur That'd be awesome, can you add me on that PR? I can close this in favor of that one.

[jlf0dev]

Closing in favor of #9364