[#8006] direct stderr to null output when running credential helper

[Smeb]

Previously, the process stderr would be combined with stdout. This meant that a credential helper which logged to stderr could cause the credential fetching logic to fail.

As described here the protocol only replies on STDOUT, so this should not break any protocol compliant helpers.

fixes: #8006

[eddumelendez]

@Smeb thanks for your contribution. Just trying to understand a little bit more about, the doc mentions The store command can write error messages to STDOUT but not for the get command, which is used for testcontainers-java. I also tried with a private repo in ECR but didn't get the error. Can you share more about it, please?

[Smeb]

Sure - basically the protocol does not expect any protocol specific information on STDERR, and only sends information on STDOUT - so we should not combine STDERR and STDOUT, because in some cases credential helpers can use STDERR for logging.

For us, we have an internal credential helper which writes log messages to STDERR - this works with Docker/Rancher etc as they don't treat STDERR as STDOUT (the behaviour this PR removes). The credential helper does not work when using testcontainers-java because the log messages on STDERR get combined with STDOUT, and then the testcontainer-java tries to read the output and runs into unexpected log messages and crashes.

To deal with this we could either store the messages on stderr and re-emit them, or drop them (the approach taken here). I don't think there's a valid use case where we should treat STDERR as STDOUT when implementing the protocol.