NON-270: Improve REST client

[ushkarev]

REST client improvements:

• Adds commonly used PATCH, PUT and DELETE methods
• Allows passing query parameters to all methods (so you don't need to build a complex url path remembering to encodeURIComponent)
• Makes response body type generic (was always unknown)

Also, propagate user types into res.locals in request handlers.

Before:

 PASS  server/data/restClient.test.ts
  POST
    ✓ Should return response body
    ✓ Should return raw response body
    ✓ Should not retry by default
    ✓ retries if configured to do so
    ✓ can recover through retries

After:

 PASS  server/data/restClient.test.ts
  Method: get
    ✓ should return response body
    ✓ should return raw response body
    ✓ should retry by default
    ✓ can recover through retries
  Method: patch
    ✓ should return response body
    ✓ should return raw response body
    ✓ should not retry by default
    ✓ should retry if configured to do so
    ✓ can recover through retries
  Method: post
    ✓ should return response body
    ✓ should return raw response body
    ✓ should not retry by default
    ✓ should retry if configured to do so
    ✓ can recover through retries
  Method: put
    ✓ should return response body
    ✓ should return raw response body
    ✓ should not retry by default
    ✓ should retry if configured to do so
    ✓ can recover through retries
  Method: delete
    ✓ should return response body
    ✓ should return raw response body
    ✓ should retry by default
    ✓ can recover through retries

[ushkarev]

cf. hmpps-auth#UserDetail

[andrewrlee]

slightly odd that some of these fields are prison specific - though activeCaseLoadId was here before anyway

[andrewrlee]

This is fine for now as it matches the auth response. I guess auth ideally would expose this as a union type

[ushkarev]

it took me quite a while to unpick what user-type info comes from where (the stuff in non-associations is more complex as it also loads caseloads) and this is the simplest thing i felt was meaningful… it's what hmpps-auth (allegedly) returns. in practice, i dunno whether all "auth sources" provide some of these fields. it felt like a sensible thing to mark the nullable ones in hmpps-auth as possibly-undefined here. the link to the UserDetail object above suggests getting caseload stuff from other apis.

still, whether this set of fields is good or good enough, i think it's nice to wire it up into res.locals – right?

auth ideally would expose this as a union type

<3

[ushkarev]

The setUpCurrentUser middleware always populates res.locals.user via the user service

[Mjwillis]

Nice work!

[andrewrlee]

think this will need to be Record<string, unknown> otherwise you won't be able to pass anything other than empty object?

[ushkarev]

Record<string, unknown> "satisfies" object. i just used the official type accepted by the superagent function:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/8139a88dd28ea580afedc673c18ceb24df95effb/types/superagent/index.d.ts#L166

[psoleckimoj]

LGTM!