Retry artifact upload/download if a 500 is hit

[konradpabjan]

Overview

We should be retrying if a 500 is encountered during either artifact upload or download.

Should fix: actions/download-artifact#33

Looking at telemetry, v1 triggers these exact same 500s very infrequently (but they do happen) so this isn't something new that all of the sudden started coming up. The v1 actions treat 500s as retryable. Anything between 400-499 is fail fast while everything else is retried: https://github.com/actions/runner/blob/6c70d53eead402ba5d53676d6ed649a04e219c9b/src/Runner.Plugins/Artifact/FileContainerServer.cs#L483

Testing

After a lot of runs, I've managed to actually hit a 500 during download, you can see in the log that it is retired and the download is successful: https://github.com/konradpabjan/artifact-test/runs/622943741?check_suite_focus=true#step:5:223

[webknjaz]

Looks like there's also some low-level socket timeout error (ETIMEDOUT) that needs to be taken into account too: actions/download-artifact#33 (comment).

[konradpabjan]

After some offline discussions, we're going to be fixing this by remapping some error codes on the server so that a 503 is returned instead of a 500. The 503 should trigger the retry logic.

[konradpabjan]

A fix is rolling out behind to scenes to make 500s that are caused by timeouts return as a 503 which will be retried.