Refactoring: Extract alertmanager http cli from amtool

[josedonizetti]

Currently, alertmanager has no client for the existing rest API. The amtool has commands that access the API endpoints, but the client code (query, and parsing) is totally coupled to it.
Also, almost no tests exist for it.

I propose we extract the query/parsing of the API from the amtool, and expose it properly in the cli package, moving the amtool commands to a new package inside the cli (e.g.: cli/cmd).

This has lots of benefits in my opinion. Eg:

1. We can adequately test the code that accesses the API, ignoring the dependencies of the cmd lib (corba/viper/etc).
2. A lib to alertmanager HTTP api can serve as a documentation REST API Documentation #511, and also allow others to write their tools on top of it.
3. It simplifies the migration from one cmd tool to another, like the one in this PR Switch amtool to kingpin #976.
4. It decouples specific features of the tool, from the HTTP client like amtool basic auth support #1028.

I'm willing to work on this if team/community thinks it makes sense.
@stuartnelson3 @brancz @mxinden @fabxc what you think?

[brancz]

This is somewhat intentional currently, as the Alertmanager API is likely to change (possibly in a breaking way, regarding client usage apart from the alert receiving endpoints). Separating and decoupling the code is a good idea anyways, but usage outside of this repo rather not recommended.

Question is, if we're already touching this, do we also want to diverge towards grpc APIs like Prometheus?

[stuartnelson3]

Code for this exists in this pr here: prometheus/client_golang#333

If you want to take over adding tests, it's basically done.

[simonpasquier]

@josedonizetti are you still working on this? If not, I can carry on.

[stuartnelson3]

@simonpasquier let me know if you start, I have some time off in a month when I was planning on doing this but it would be nice not to duplicate work :)

[stuartnelson3]

closed by #1278