feat(user_roles): Add accept invitation API and UserJWTAuth

[ThisIsMani]

Type of Change

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

Description

This PR will add a new API for accepting invitation and also a new JWT auth type which has only user_id.

Additional Changes

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

Motivation and Context

To support the Accept Invite flow in the following flow.

flowchart TD
    A["Connect Account"] -- Email --> B{"User Exists"}
    B -- No --> C["Create new \n Org \n Merchant \n User \n User Role"]
    C --> D["Send Verify Email"]
    D --> E["Verify Email Token"]
    B -- Yes --> D
    E --> H{"Is there\n any perferred \nmerchant"}
    F -- ==0 --> I{{"Send list of \nmerchants which\n user has access to\n along with an\n intermediate token"}}
    F -- >1 --> G[Select the first role with active status]
    H -- Yes --> M["Send the token \nwith that merchant_id"]
    H -- No --> F{"How many \n active merchants\n does user have \naccess to"}
    I -- merchant_ids, \nintermediate_token --> O["Accept Invite"]
    subgraph Accept Invite
        O --> P["Change status to active"]
        P --> G
        G --> M
    end
    K["Sign In"] -- Email, Password --> H

Loading

How did you test it?

curl --location 'http://localhost:8080/user/user/invite/accept' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer JWT' \
--data '{
    "merchant_ids": [
         "merchant_id1",
         "merchant_id2",
         "merchant_id3"
    ],
    "need_dashboard_entry_response": true
}'

If any of the merchant_id status is active, then you will be getting the following response.

{
    "token": "JWT with merchant_id, user_id, user_role",
    "merchant_id": "merchant_id",
    "name": "user name",
    "email": "user email",
    "verification_days_left": null,
    "user_role": "user role"
}

If need_dashboard_entry_response is false or not sent, then the response will be 200 OK.

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
• I added a CHANGELOG entry if applicable

[racnan]

Lets give this API the possibility to not send the signin payload as response payload. Maybe query params?

[racnan]

Check if need_dashboard_entry_response needs to be in query param.