Make PDS adapter steps resilient to network problems

[de-jcup]

Situation

After #2273 we are able to deploy continously new PDS versions. That works fine when we have K8s and use the continous deployment there.

But when we have only ONE instance for the PDS defined, and we directly kill the PDS process we have a downtime and there is no response to SecHub server while executing a SecHub job via PDS adapter:

None of the consultants (1) gave any proposal, so rethrow exception
 org.springframework.web.client.ResourceAccessException:
I/O error on GET request for
"https://single-instance-pds-scancode:8123/api/job/33d5b1ce-f558-4da5-834c-771ab97246ba/status": 
Connect to single-instance-pds-scancode:8123 [single-instance-pds-scancode/192.138.120.134] failed: 
Connection refused; nested exception is org.apache.http.conn.HttpHostConnectException: 
Connect to single-instance-pds-scancode:8123 [pds-scancode/192.138.120.134] failed: Connection refused
...

The same when there would be any network connection problems.

Wanted

When there is temporary no communication available to PDS server, the PDS adapter call shall be resilient and retry the current step

Solution

Provide a resilience consultant for PDS adapter which is configurable (by executor configuration parameters) and has some nice defaults.
It shall be able handle per default 3 resource access exceptions and to wait 10 seconds before retry.

Details

Normally the resilience consultants are used by product executors, but it makes more sense to use them inside PDS adapter directly for every single step to avoid breaking the complete running PDS execution (and retry by PDSResilienceConsultant)

For example: when the upload is not possible because of network problems, try it multiple times, if the job creation does not work, try it multiple times, if the job wait fails, try ONE wait multiple times before final exit...

Existing PDS resilience part in executor

After investigating and fixing #2281 there is the question if the PDS resilient consultant is really still helpful here or if the resilience logic shall all be done inside the adapter because of treating steps better.

PDSResilienceConsultant does handle HttpClientErrorException errors, means: There is at least connection available and those errors should normally not happen because of network problems.

Because this another type of error, we keep PDSResilienceConsultant as is at the moment (maybe later we could move this error handling also into the adapter, but this is not part of this issue).