These were previously causing flaky tests due to latency in the config
push from GCP -> TD, meaning that the clients were launching before the
new config was actually available to the client. These tests now launch
a "exploratory" client process before initiating the test to ensure that
the expected backends are receiving traffic before the test begins.
(The existing checks rely purely on GCP API, e.g., checking if the
backend service reports healthy. There can be slight delays before these
status changes are actually available in the xDS response sent to
proxyless clients).
Downloads fail from time to time because Gradle does not retry certain
types of network failures
(https://github.com/gradle/gradle/issues/8264).
Retrying twice should reduce the flake rate below noticeable without
increasing the size of the interop image created for each new release
for historical testing.
Fixes#18892
Ideally instead of having names like ruby_jessie_x64_ruby_2_5 and
ruby_jessie_x64_ruby_2_6 they would have the name "ruby" with tags
containing jessie_x64_ruby_2_5/6. But fixing that would be much more
invasive. The sha1 in the tag is producing the worst effects, so this is
a case of the perfect being the enemy of the good.
Fixes#20546