feat: Introduce transfer type

[wolf4ood]

What this PR changes/adds

Introduce the transfer type concept as outlined in the DR #3637.

Adds the transfer type field in:

• TransferRequest
• DataRequest
• TransferRequestMessage
• DataFlowRequest

and their transformers when necessary.

The TransferRequest#dataTestination (DataAddress) is still mandatory, even in the case where the transferType could be enough for the transfer, like in the PULLs scenarios (Backward compatibiliy).

The EDC DataFlowControllers :

• ConsumerPullTransferDataFlowController
• ProviderPushTransferDataFlowController

have been slightly modified to be backward compatible in case they receive the transferType field.

Why it does that

Decouple the type of transfer from the DataAddress#type of the destination in a transfer request

Linked Issue(s)

Closes #3724

[ndr-brt]

why is transferType added on DataRequest? This value object has no particular use in the current implementation so I would add transferType directly on the TransferProcess

[wolf4ood]

@ndr-brt no particular reason, all the DSP/ protocol related informations are stored in the DataRequest that's why I put that there. If i remember correctly we wanted also the merge those two. For me it's fine to put that in TransferProcess

[ndr-brt]

@ndr-brt no particular reason, all the DSP/ protocol related informations are stored in the DataRequest that's why I put that there. If i remember correctly we wanted also the merge those two. For me it's fine to put that in TransferProcess

yes, the merging process proceeds really slowly 😁 I think we should not add new stuff on the DataRequest but that should be done directly in the TransferProcess.
To inline the DataRequest we'll need to change some apis first, like the ResourceManifestGenerator.
I created the issue so that we won't forget: #3732

[wolf4ood]

Cool make sense :)