TransferProcess: remove unnecessary REQUESTED_ACK state

[ndr-brt]

I got no responses to the discussion about the REQUESTED_ACK state, so with issue I propose to delete it.

Discussed in #629

^{Originally posted by ndr-brt February 7, 2022}
Going through the TransferProcess state machine I noticed this REQUESTED_ACK state.
This state, according to the code and the docs, can be reached only on the consumer side, and at the moment there's only one point where there's such state transition:
after the provision is complete, the TP is set in REQUESTED state and the data request is sent to the provider, if the response is successful, the TP is moved to REQUESTED_ACK and moved suddenly to IN PROGRESS (or STREAMING).

There's also a checkProvisioned() method that fetches TPs in such state to move them in IN PROGRESS (or STREAMING), but probably never won't find anything.

To follow the "state machine pattern" that was defined in #613 probably we would remove the REQUESTED_ACK state, and for the PROVISIONED TP the process should be:

• put it in REQUESTED state
• send data request to provider
• if response is successful, move it to IN_PROGRESS or STREAMING
• if response is failed, move it to PROVISIONED if there's a retry strategy set or to ERROR elsewhere.

[jimmarino]

I'm not sure we can remove this. For example, after the ack is received from a request, there may be some time before the data transfer is put in progress (or streaming) on the provider side. Also, there is the case where the provider has to issue a key for the client to access the data and that happens sometime after the ack is received.

The code that transitions immediately from ACK to IN_PROGRESS/STREAMING was a temporary workaround until we implement the notification mechanism.

Maybe this is something we should look into further for M3?

[ndr-brt]

Ok, seems reasonable, however this makes me feel like we have a discrepancy in the state naming convention.
At the moment there are these states:

• REQUESTED (I'm about to call the provider)
• REQUESTED_ACK (the provider responded successfully)

But, if I take a look at other cases e.g. in the *ContractNegotiationManagers, the pattern is (for example):

• CONSUMER_OFFERING (I'm a about to call the provider)
• CONSUMER_OFFERED (the provider responded successfully)

So maybe the two TransferProcess status should be called REQUESTING and REQUESTED, this would give more cohesion and reduce confusion.

[ndr-brt]

This was done in #831