fix(users): Check key manager runtime feature flag when calling transfer key

[ThisIsMani]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

We use transfer_key_to_key_manager to transfer key to the encryption service. When that function was introduced in the user module, there was only compile time feature flag. Afterwards a runtime feature flag is also introduced which when disabled, the expectation is the encryption service is not supposed to be used.

When this runtime flag is introduced, the user code was not updated to check if the runtime feature flag is enabled before calling the transfer function. Because of this, the code is trying to transfer the key to encryption service even when the runtime feature flag is set to false.

Ideally, this check should've been in transfer function itself since that is how all the other functions (crypto_operation) functions are written.

This PR adds check in transfer_key_to_key_manager function which checks if the runtime feature flag for key manager is enabled or not.

This was being done manually before, and was not added in user part of code, which caused some problems, so, I moved the check to the transfer function itself and callers doesn't have to check this manually from now on.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

Closes #4071

How did you test it?

Ran both Hyperswitch and Encryption Service locally. Turned on the encryption_service compile time feature flag in Hyperswitch.

Turned on the runtime feature flag, created a user, which creates merchant and setup TOTP, both merchant and user related operations are done in this flow along with encryption and decryption. Everything worked in this case.

Turned off the runtime feature flag and logged in with the old user, which also worked. - This was the main problem before.

Created a new user in this state (runtime flag turned off).

Turned on the runtime feature flag and logged in again with both users. Second user has fell back to local decryption since the key is not present in encryption service, everything worked as expected.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/types/domain/user.rs	80% smaller
crates/router/src/core/admin.rs	59% smaller
crates/common_utils/src/keymanager.rs	48% smaller
crates/common_utils/src/types/keymanager.rs	0% smaller
crates/hyperswitch_domain_models/Cargo.toml	Unsupported file format
crates/hyperswitch_domain_models/src/type_encryption.rs	0% smaller
crates/payment_methods/Cargo.toml	Unsupported file format
crates/router/Cargo.toml	Unsupported file format
crates/subscriptions/Cargo.toml	Unsupported file format

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@46bb969). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #10859   +/-   ##
=======================================
  Coverage        ?        0           
=======================================
  Files           ?        0           
  Lines           ?        0           
  Branches        ?        0           
=======================================
  Hits            ?        0           
  Misses          ?        0           
  Partials        ?        0           

☔ 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.

[ThisIsMani]

To check if the dependencies are being enabled correctly or not, I've disabled encryption_service feature flag in router and enabled the runtime feature flag.

I've added a piece of code in the /health/ready api, which logs the output of the is_encryption_service_enabled function.

With the old feature flag dependencies, with the above setup, the log outputs true even though the compile time feature flag in router is disabled.

With the new ones, the log shows false, which is expected.

[ThisIsMani]

These dependencies are fragile though. There is a very high chance that somebody would later use wrong dependency graph, which will revert back to the old behaviour.

EDIT: Should not be a problem because in all the images we give out, encryption_service feature flag is enabled.

[tsdk02]

Minor nit, other than that, looks good to me!

[sai-harsha-vardhan]

Instead of having feature flag based branching in a fn, we can have two definitions for v1 and v2 right