feat: Setup AsyncLocalStoreage context for Express.User throughout the callstack

[DafyddLlyr]

What does this PR do?

• Creates a context object to store the user which will persist throughout the callstack of a request/response cycle
• Uses the Node AsyncLocalStoreage API to acheive this (docs)

Why this approach?

We need to keep user details, specifically the JWT and user ID, for a number of operations that happen in the API. The specific issue we're hoping to address in the short term here is ensuring that any requests made the the API are scoped to the permission level of the user who made the request.

We always have req.user as the express-jwt middleware sets this up for us. If we wanted to access this value in a service, or a child function of that service, we'd need to "prop drill" the request or user object all the way through. This approach can get out of hand quite quickly and can be tricky to manage.

Using AsyncLocalStorage we get the following benefits -

• We can easily access the userContext at any "depth" - a good expansion of this would be error logging - we can tell which user triggered an error now by calling userContext within our error handling operations.
• We can easily add or remove data from the typed userContext object if needed
• It's "thread safe" (for lack of a better term) so we can handle multiple users with multiple permission levels making requests all at once with confidence.

Testing

One thing I've not yet hit in any of our examples so far - it's likely we'll need to mock the userContext in some tests. Right now as we're using supertest and testing mostly via the API endpoints this is all set up for us. In more service-specific tests this might be a consideration.

Next steps...

• There's a few $admin calls still remaining - tidying these up are low priority relatively so I've just marked as @depracted for now so we don't add any more and we can tidy these up as we go?

Diagram

This encapsulates the changes made in #2198 and #2199

sequenceDiagram
    participant Origin
    participant API

    box Middleware
    participant useJWT
    participant useRoleAuth
    end

    box userContext
    participant Controller
    participant Service
    participant Child Function
    end

    Origin ->> API: Send Request
    API ->> useJWT: 
    useJWT ->> useJWT: Validate & decode JWT

    alt Unauthorized
        useJWT ->> API: Error
        API ->> Origin: 401 Unauthorized
    end

    alt Forbidden
        useJWT ->> useRoleAuth: 
        useRoleAuth ->> useRoleAuth: Validate role
        useRoleAuth ->> API: Error
        API ->> Origin: 403 Forbidden
    end

    alt Permission Granted
        useRoleAuth ->> Controller: Setup userContext
        Controller ->> Service: 
        Service ->> Child Function: 
        Child Function -> Service: 
        Service ->> Controller: 
        Controller ->> API: Success
        API ->> Origin: 200 OK
    end

Loading

[DafyddLlyr]

Not thrilled on the naming here - feels a little generic and meaningless.

Something like getUserRoleClient() might be more accurate but it's pretty wordy...

No strong opinions here on naming, but if we move to a future where the API only calls a $public client (pretty clear what this is) and a permissions-scoped $client then this might actually be fine?

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

➕