Add the ability to allow curl to retry the request, particularly for recovery

[clauderobi]

Hello,

This is in fact an enhancement request for the tang pin

In some cases, it may be useful to have the curl request to retry the request to the server. Obviously the thing that calls clevis could implement it itself but it is not always possible. Also, curl already has an extensive retry framework, including the ability to honor the Retry-After header in the reply from the server.

We can see a few use cases, such as:
1 - The tang server is only started when necessary and turned Off at other time. When needed it is started. But making sure it is fully started BEFORE the client(s) needs it would add an unnecessary complexity.
2 - Some gating procedure expend on the previous use case by allowing / disallowing access to tang. The first request would trigger something to ask for permission and disallow the request. An ulterior request would then be allowed.

A solution would be to allow passing arbitrary arguments to curl. Or have something specific.

What do you think?

[oldium]

I have another use case - power-outage recovery. When there is power outage, all systems boots-up at the same time - including the tang server. The boot of tang server (running on application server) takes much longer than entering the boot stage of the protected device. Thus retrying (in the sense of the maximum time spent in the retry loop) would be necessary for this situation.

[oldium]

And a note: It cannot be curl, who is retrying, simply because it would freeze the clevis unlocking loop. The retry needs to be controlled - so inside the clevis loop. But allowing to pass arbitrary arguments to curl would be good anyway.