Write an ADR for use of a user's JWT now that EdxApiRestClient has been removed

[robrap]

During the DEPR of EdxApiRestClient, some cases were replaced with plain requests object code, rather than using the updated OAuth client, using the user's JWT for service-to-service calls.

TODO: Find an example link of this change from the DEPR work.

The original intention of the new client was intentionally not to add this functionality to the new client, because it was thought that the client credentials token should be used instead of the user's JWT.

• We should have an ADR that clarifies when and if using the user's JWT is appropriate.
  • We might potentially enhance the existing client if we wish to allow for other ways of using it.
• Note: The new client also provides shared observability code, but is lost when using the requests code directly without a client.
• The Authentication OEP should also link to this ADR.

[robrap]

Other thoughts to consider: How might different solutions affect traceability and rate limiting.

Note: If we enhance the client with additional features around retries, backoffs, circuit breakers, etc., we'll have even more reasons for people to use our client over requests directly.

[robrap]

Note that once this ADR exists, there should be a follow-up ticket for getting the platform aligned with the decision.

[robrap]

Additional notes:

• Review the original client for code that was lost. For example, the setting of the User-Agent here: https://github.com/openedx/edx-rest-api-client/blob/2388c71aa0c782720f40491ad75a4bce6bf68dbf/edx_rest_api_client/client.py#L355C25-L355C37
• Updated code did not use a new client, but it did use SuppliedJwtAuth. This class can probably be used to find usages outside of the library in the case we wish to replace with a full client.

[robrap]

If we are unable to make a decision, we could at a minimum document the de facto decision that was made for all the legacy code in a how-to and/or ADR.

[robrap]

Note that in general we should be avoided doing synchronous calls to other services within a user's request. This is one reason why we may want to avoid reuse of the user's existing JWT in general. However, it may be ok to do so for the exceptional cases where a synchronous call is required. Note that there may be legacy calls which could be refactored, and these should possibly be documented as such.