Client server updates are attempted in full

[arussellf5]

Proposed changes

Client's UpdateHTTPServers and UpdateStreamServers methods now attempt to update all servers and return a combined error

Previously these methods would return as soon as an error was encountered. Now they attempt to apply all the server updates and collect all errors encountered along the way. The reasoning behind this is that we want to apply as many of the desired changes as we possibly can and don't want any transitory errors that may affect a single server update to cause all the rest of the updates to be skipped.

Use case:

I work for the NGINXaaS for Azure team and we using the plus client to apply on-the-fly upstream server updates to deployments linked with kubernetes clusters. Our aim is to react to scaling and other events on the cluster by applying the server updates to the customer's dynamic upstreams. We want to apply as many of the server updates as we can through a single call to UpdateHTTPServers() or UpdateStreamServers().

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

[github-actions]

✅ All required contributors have signed the F5 CLA for this PR. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[arussellf5]

I have hereby read the F5 CLA and agree to its terms

[UnwashedMeme]

This looks pretty good to me.

[jjngx]

Hey @arussellf5, do all tests pass when you run make? Ok, I see now.

LGTM

[jjngx]

🚀

[sjberman]

The one downside I could see with this is that if there's some error connecting to the API, and you're trying to update 1000 upstreams, you're going to get a massive error message.

[arussellf5]

The one downside I could see with this is that if there's some error connecting to the API, and you're trying to update 1000 upstreams, you're going to get a massive error message.

@sjberman I agree that this situation sucks. But consider another scenario where there is a single malformed upstream server in the update list. The current behavior might prevent all other 999 servers from getting updated, because of a problem updating a single server. I think that this change will be worth it to address that scenario, even if there are some downsides.

[sjberman]

@arussellf5 That's fair.

[arussellf5]

@jjngx @sjberman if one of you two has the privilege to merge to this repo, would you please do that, because I'm not authorized to do so? Thanks