refactor(core): moved the fingerprint_key_hash from configs to merchant_account table

[prajjwalkumar17]

Type of Change

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

Description

fingerprint_hash_key which is used by hyperswitch_card_vault for performing HMAC hash on the payment_method_data for storing it.
We had this value previously stored in configs table in raw String.
We have refactored it, to be stored in merchant_account table(encrypted beforehand by our DEK).

Additional Changes

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

ALTER TABLE merchant_account ADD COLUMN IF NOT EXISTS fingerprint_hash_key BYTEA DEFAULT NULL;

Motivation and Context

How did you test it?

Generating fingerprints

1. Toggle the blocklist guard from merchant account being used using /blocklist/toggle?status=true. More about
   toggling guard here.
2. We need to create a payment.
3. While trying to confirm the payment it will have the fingerprint_id in the response. This can be used to block the
   instrument. If the payment was able to be captured the fingerprint will be stored in the intent table as well

Blocking fingerprints

Refer to the attached postman collection for the API contracts for the blocklist APIs(Description). Currently we support blocking three types of resources i.e. card numbers (payment intrument), card bin, and extended card bin.
blocklist_api_postman.zip

Once fingerprint(from the above point 2) is generated,
and for the created merchant, we can find in merchant_account table that the col fingerprint_hash_key exists and has some value, we can be sure that this refactor is working fine.

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