network: do not retry on 429 and 503

[FiveOFive]

Overview

This is fix for when ZAP is stuck waiting to retry requests after receiving a response with the retry-after header set. See zaproxy/zaproxy#8627

Related Issues

Fix zaproxy/zaproxy#8627.

Checklist

• Update help
• Update changelog
• Run ./gradlew spotlessApply for code formatting
• Write tests
• Check code coverage
• Sign-off commits
• Squash commits
• Use a descriptive title

For more details, please refer to the developer rules and guidelines.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[FiveOFive]

I have read the CLA Document and I hereby sign the CLA

[thc202]

This should have tests.

[thc202]

fwiw, it would have been better if this was added to the rate limiter rather than stopping completely.

[kingthorin]

List.of()

Vs Arrays.asList()

[FiveOFive]

Fixed

[FiveOFive]

This should have tests.

I've added a test for both 429 and 503 status codes

[FiveOFive]

fwiw, it would have been better if this was added to the rate limiter rather than stopping completely.

Would that be an additional change in combination with this PR or instead of this PR? I didn't see how the rate limiter could help with the behavior of the underlying http client retry strategy, but I'm not that familiar with the networking code here. Let me know if the team prefers a different solution.

[thc202]

#5727 (comment)

Looks good but we should verify the behaviour more broadly.

#5727 (comment)

It does not need to be in this PR. It would be an improvement for the rate limiter, this change/PR is still needed either way.

[thc202]

Thank you!