[PM-24051] MasterPasswordUnlockData model with response mapping and adds it to identity success response model

[mzieniukbw]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-24051

📔 Objective

Adds MasterPasswordUnlockData model with MasterPasswordUnlockResponseModel mapping. This wi
Adds UserDecryptionOptionsResponseModel into the identity success token response. This model includes the master password unlock field.
The /sync response model is autogenerated by OpenApi and already includes user decryption option and the master password unlock fields.
Includes Uniffi and WASM bindings for MasterPasswordUnlock.

In further PR's we plan to use the MasterPasswordUnlock in InitUserCryptoMethod enum - this is still in discussion.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
  team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
  issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[github-actions]

Checkmarx One – Scan Summary & Details – 2655eb53-8e8e-4df0-9bcd-e467613a40ae

Great job! No new security vulnerabilities introduced in this pull request

[codecov]

Codecov Report

❌ Patch coverage is 90.13453% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.35%. Comparing base (bceb681) to head (2591773).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...twarden-core/src/key_management/user_decryption.rs	0.00%	19 Missing ⚠️
...twarden-core/src/key_management/master_password.rs	98.52%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #376      +/-   ##
==========================================
+ Coverage   74.19%   74.35%   +0.16%     
==========================================
  Files         253      255       +2     
  Lines       21897    22120     +223     
==========================================
+ Hits        16247    16448     +201     
- Misses       5650     5672      +22     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[quexten]

Some initial comments, some of these are required, some are idiomatic (but probably required since the quality bar for SDK seems to be set much higher).

I'd like a review from someone with more rust experience such as @Hinton or @dani-garcia too. I believe specifically the request parsing is something that has not existed in the SDK so far, and there may be a better way to do this that we're unaware of.

[quexten]

Looking pretty nice now! Some more smaller items that improve usability by teams unfamiliar with the code (docs / error names)

[Hinton]

This tightly couples consumers of the SDK to the server generated bindings which is somewhat dangerous. We've previously addressed this by wrapping requests/responses in a manner that more accurately represents the action from the SDK's perspective. There be dragons here and we should consider this a bit.

Do we expect to do similar things to other request/responses? If not I think we should simply wrap the logic with our own struct, while it's a few lines of boilerplate it reduces the complexity.

Includes Uniffi and WASM support.

There is no UniFFI support here.

[Hinton]

issue: The PR title mentions sync response, there is nothing touching sync here.

We should be careful about introducing public objects that are not consumed. Once something is public it's technically a breaking change to flip the visibility and if you don't know fully what needs to be public it's easy to accidentally leave public remnants that should be private.

In these case just making items private and going back later and flipping the visibility where necessary can be useful. Which can also assist with documentation since documentation should be written from the consumers standpoint which is hard when you don't have the interfaces making it public.

[Hinton]

question: Is there a reason for not just using require!?

Suggested change

	memory: kdf_parse_nonzero_u32(
	response
	.kdf
	.memory
	.ok_or(MasterPasswordError::KdfMalformed)?,
	)?,
	parallelism: kdf_parse_nonzero_u32(
	response
	.kdf
	.parallelism
	.ok_or(MasterPasswordError::KdfMalformed)?,
	)?,
	memory: kdf_parse_nonzero_u32(require!(response.kdf.memory))?,
	parallelism: kdf_parse_nonzero_u32(require!(response.kdf.parallelism))?,

[mzieniukbw]

@quexten pointed out, that it might be better to consolidate all KDF related verification into the KdfMalformed error. Using require! would provide non-KDF specific error.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[quexten]

Looks good from my side.