Feature/mi 19 bigcommerce token and customer services

[tvhees]

Provide services for the following operations commonly used in the mesh:

• Get the customer impersonation token, from the cache if possible
• Generate a JWT for a logged in customer, and extract their customer id from such a JWT

I have also:

• deprecated existing methods for these operations
• used the token service for automatically injecting the customer impersonation token in the graphql client
• modified two resolvers to use the new services as examples

[tvhees]

@brettcutt-aligent I see that you've previously implemented this as a Request class in client work, which I think makes sense for at least the customerId part of this. I'm interested in where you think the service boundaries should be here (general tokens, per-request information, customer information etc.) and very open to re-architecting this

[brettcutt-aligent]

@brettcutt-aligent I see that you've previously implemented this as a Request class in client work, which I think makes sense for at least the customerId part of this. I'm interested in where you think the service boundaries should be here (general tokens, per-request information, customer information etc.) and very open to re-architecting this

@tvhees What you have in this PR looks good and follows along with the discussion of last weeks meeting. Ideally I would rather have a service which handles all the required request headers in one spot but couldn't be sure of the best approach to allow certain requests even if authentication fails e.g. storeConfigs`.

[brettcutt-aligent]

Do we need to set a fallback value if there's already one set in constants.ts?``

[brettcutt-aligent]

can this live in constants.ts?

[brettcutt-aligent]

Not for this PR but it would be great if we could extract the xray logic into sub functions. I find the main caching logic is hard to read.