Incorporate and extend EDC's new /edrs controller

[paullatzelsperger]

WHAT

Upstream EDC has a new implementataion of the /edrs API, onto which the Tractus-X implementation will be based. In essence, it will change the way how we query EDRs, and response bodies will be based on a new JSON schema.

1. Automatic EDR renewal

As a convenience feature, the GET /edrs/<ID>/dataaddress (formerly known as GET /edrs/<ID>) will get a new optional query param, that toggles the auto-refresh of access tokens:

GET /edrs/<ID>/dataaddress?auto_refresh=true

setting the auto_refresh=true will cause the controller to inspect the access token of the EDR and check if it's expired, and if so, renews it automatically (delegating to the TokenRefreshHandler, issue #1112 / pr #1126).

Note: the default behaviour is indeed to perform automatic renewal of the access token.

2. Explicit EDR renewal

In addition, the Tractus-X EDR API gets extended, adding one new endpoint to allow consumers to manually trigger renewal of access tokens:

POST /edrs/<ID>/refresh

which triggers the refreshing of the token, again using the TokenRefreshHandler. The response body will contain the new access and refresh token.

WHY

In situations where the consumer data plane is not used to perform the data transfer, client applications may or may not need to know about token renewal, so the EDR API can handle that transparently. At the same time, it is always good to have a fallback way to trigger token renewal explicitly.