EDR Token Refresh auto refresh result is non deterministic

[rafaelmag110]

Describe the bug

The GET /edrs/{transferProcessId}/dataaddress using auto_refresh as true should always return a non expired access and refresh token pair. For this to happen, the connector will verify the expiry of the token and trigger a refresh when its due.

In practice, multiple clients can request the same EDR in an (quasi-)parallel manner, i.e. a job that spans to multiple workers and all require the same EDR. When such happens, and the requested EDR is in a expired state, all the requests will trigger the automatic refresh of same token. Here is where the problem occurs.

Considering the ideal requesting scenario:

Client A issues the refresh request, and token A' is created and stored in the server.
Client B issues the refresh request, and token B' is created and stored in the server.
Client A received token A' and stored it in the database.
Client B recevied token B' and stored it in the database.

Server has B' as the active token and the clients have B' as the active token. The system state is as expected.

However, the following can happen:

Client A issues the refresh request, and token A' is created and stored in the server.
Client B issues the refresh request, and token B' is created and stored in the server.
For some reason, Client B might received token B' first and store it in the database.
When client A receives token A', and stores it in the database, the system state will be inconsistent, as the server has B' as the valid token.

From this point onward, all token validations will fail, rendering the tokens useless and preventing any new token refresh on the same EDR.

Context Information

Problem is found in EDC versions 0.7.X and up.