Introduction of a ProvisionerManager interface

[ndr-brt]

We are on the refactor of the ProvisionerManager to make it return a CompletableFuture and so working all in asynchronous way. (see #451)
Doing this we set the interface methods like these:

List<CompletableFuture<ProvisionResponse>> provision(TransferProcess process);
List<CompletableFuture<DeprovisionResponse>> deprovision(TransferProcess process);

Because, from a process, more than one resources can be provisioned.
Goin' on with the refactor I noticed that there are two kind of provisioned resources: ProvisionedResource and ProvisionedDataDestinationResource (at the moment in the codebase we are using only the latter).

ProvisionedDataDestinationResource represent a resource that will be the destination for the data, and, from some discussions, it seems like that for a single transfer there should be just one of it (or none?).
ProvisionedResource represent a generic resource that can be used in a context of a transfer but that does not handles the transfer data.

I opened this discussion to gather some ideas and try to improve that interface, because, at the moment, the transfer process can be updated on every resource provisioned, e.g. if there are 3 resource, the transferprocess is updated 3 times, but that's not correct, because the provision phase is one, and it should be executed as a whole (does it?).

a proposal from myself about the interface is:

CompletableFuture<ProvisionResponse> provision(TransferProcess process);
CompletableFuture<DeprovisionResponse> deprovision(TransferProcess process);

and introducing inside the ProvisionResponse one field that represent the ProvisionedDataDestinationResource that could be null and a list of ProvisionedResource. Doing that the result of a provision/deprovision would be valuated only one time.

[jimmarino]

The PROVISION phase has a start and completion but it is an async fanout that has 1..N callbacks. These callbacks can return at various points in time.

This could be modelled by a single response but then the ProvisionManager will need to coalesce the results from the fanout. Doing so would have the advantage of moving that out of the TPM. The other thing it may make easier is determining when all of the provisioned resources have completed. Currently, this is done in the TPM by comparing the number of resource definitions to received provisioned resources.

The important thing is the ProvisionManager must not block (e.g. join) on the fannout as that will block the TPM tick thread.

Is this something you think we should try before the command queue?

[paullatzelsperger]

The more I think about this, the more I like the idea of the TPM simply delegating out to the ProvisionManager, and receiving one result as opposed to several. It would reduce the complexity of the TPM.

Another thing to remember is that we should never hold secrets in memory longer than absolutely necessary, rather we should store them in the vault as soon as possible.

[ndr-brt]

@jimmarino @paullatzelsperger I agree with both of you, the ProvisionManager should be a non-blocking collaborator of TransferProcessManager that takes care of all the provision phase of a single TransferProcess.
The ProvisionManager will take care of the fanout, asyncronously (using the CompletableFuture.allOf) method.

I would implement that directly in #451 if you agree