Revert "signing re-try" logic once eclipse signing service becomes reliable

[andrew-m-leonard]

The eclipse signing service is intermittently un-reliable, sometimes failing with http 502, sometimes just not signing the executable and returning a html response stream, sometimes seemingly being ok but the executeable is not signed!
ref: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3758

The retry logic is in the following places:

• temurin-build/sign.sh

  Line 174 in 751e5c8

  max_iterations=20

• temurin-build/sign.sh

  Line 89 in 751e5c8

  # Retry up to 20 times

• https://github.com/adoptium/ci-jenkins-pipelines/pull/823/files

[netomi]

A version of the authenticode signing service for Windows that supports multiple timestamp servers has been deployed to staging and been successfully tested to work as expected.

It will be deployed to production this evening.

The failures wrt the windows signing in the past couple of weeks were always related to the timestamp server not accessible or reachable. So with this fix this should be resolved.

The failures we have seen on the macos signing service were related to the environment on which the service was running. There were failures for a couple of days as the disk was full, thus retries were also failing.

So imho, the occasional failures on windows should be resolved as we have then 3 timeservers configured and they will be tried if one of them fails, avoiding the need to retry on build level. The failures we have seen on macos would be persistent and resilient to a retry. We need to tackle that by better monitoring of the signing services.

One option that we are currently explore is to deploy the macos signing service also in our openshift cluster, which was not possible so far as we needed the actual macos signing tool, but we found now an alternative implementation that does not require to run on macos.

[netomi]

improved windows signing service is now deployed to production.