Fix Alerting Http Client

[alexandreLamarre]

• Fix the HTTP alert client struct
• Fix the controller backoff logic
• Make API pipelines when needing to call multiple async apis that can depend on each other

[alexandreLamarre]

Made the required enhancements, they are now used by alerting.endpoint.proto / alerting.condition.proto

[alexandreLamarre]

TODO, need to fix :

• the internal trigger api in api.go still uses the old way of using the client, need to fix that
• the tests use the old api client, so they either will fail or failed to compile

[alexandreLamarre]

Still can't fix the pre-existing "race condition" with /test api that triggers an alert with the given credentials where it may not trigger the alert

The crux of the issue is comparing the output of /api/v2/status to the newly applied config in the at the end of the AlertManager reload API pipeline

(The new client is more robust to failure but exacerbates the stuttering that can occur during reload)