CT: Unblock submit early if a log returns an error

Our current CT submission process is:

• Randomly shuffle the list of log operators we submit to
• Simultaneously kick off submission requests to logs operated by the first two
• Sleep, then kick off a third request, sleep, then the fourth, sleep, etc
• Abort as soon as we get two successes

However, this means that, if one of the first two logs immediately fails, we wait and do nothing before kicking off the backup request. It would be great to have a mechanism that immediately kicks off the third (or fourth, etc) request as soon as it knows that it is impossible for the current set of in-flight requests to generate two SCTs.

A rough draft of this was implemented in https://github.com/letsencrypt/boulder/pull/7151. This solution works, but causes the queue of waiting goroutines to behave in surprising ways. I'm filing this bug to keep the idea on file while we close that PR for the time being.

Start by reviewing the rough implementation in pull request 7151 and its handling of the CT submission goroutines and queue. The change is done when a failed in-flight log causes the next submission request to start immediately whenever two SCT successes are no longer possible, without introducing surprising queue behavior.