Issue:
feat(auth): Support profile level authentication


- After the dashboard is changed to profile level, there will be 3 types of APIs based on the level
	1. Merchant Level only
		- API Keys
		- Merchant Account
		- Business profile
	2. Profile Level only
		- Connectors
		- Routing
		- Operations (Payment, refund, disputes except list and filter)
		- etc...
	1. Profile + Merchant
		- Operations list and filter
		- etc...

### Merchant Level APIs
- No changes here.

### Profile Level only
- These should start accepting an optional profile_id in the function parameter, which will be passed from auth layer.
- There are some APIs which are currently at pseudo profile level like payments create and refunds create.
	- Currently these kind APIs take profile_id in the payload or query param.
	- From now on, these should not accept these in the request and take those values from the auth layer.
- To support the current API calls, these will fallback to body if profile_id in header is not present.

### Profile + Merchant Level
- These APIs should operate both in merchant level and profile level.
- These APIs accept a vec of profile_ids in the function parameter.
- There should be different routes for these APIs and probably the core function will remain same.
	- The route function will be different for each route but calls the same core function.
	- If the profile_id vec is not empty, then the API will send the data for those specific profile_ids else for the whole merchant.

## Breaking changes
- Current APIs will be changed in a way that the current calls will work without any changes. So there shouldn't be any breaking changes.

## Auth
- Auth layer will now give either
	1. org_id, merchant_id and profile_id
	2. org_id, merchant_id and Vec<profile_id>
- There are currently two types of JWT Auths.
	1. JWTAuth
	2. JWTMerchantFromRoute
- Both of these will have a new implementation which will send the data as mentioned in the first point.
- Both of these have profile_id as optional type for backwards compatibility.

- Once we have a stable version where profile_id is always present in the JWT, then we can have following JWT Auths for more checks.
	1. JWTAuth
	2. JWTMerchantFromRoute
	3. JWTProfileFromRoute
	4. JWTMerchantAndProfileFromRoute
- These will always have profile_id in the payload.

- Routes can choose to pass or not to pass the profile data to the core function.

Resolution:
<think>
PR Context:
- Title: feat(auth): Add `profile_id` in `AuthenticationData`
- Merged: 2024-08-01T14:04:04Z
- Files changed: 7 files
- Commits: 10 commits

Implementation approach:
## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [ ] Bugfix
- [x] New feature
- [ ] Enhancement
- [ ] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->
Since we are going to change the dashboard to profile level, we need profile level authentication. 
This PR introduces profile_id in the AuthenticationData. Core API will take this into consideration before sending any response.

### Additi
</think>

To implement this, you'll need to modify:


**Detailed Implementation:**


**Commit 1:** feat(auth): Add `profile_id` in `AuthenticationData` (#5492)
Files to modify:


**crates/router/src/core/user.rs**
  Modify existing code

**crates/router/src/core/user_role.rs**
  Modify existing code

**crates/router/src/db/merchant_account.rs**
  Modify existing code

**crates/router/src/services/authentication.rs**
  Add:
    - struct: pub::AuthenticationDataWithMultipleProfiles

**crates/router/src/types/domain/user.rs**
  Modify existing code

**crates/router/src/types/domain/user/decision_manager.rs**
  Modify existing code

**crates/router/src/utils/user.rs**
  Modify existing code