Refactor cog-api

[christophermaier]

From @mpeck on November 29, 2016 20:56

Cog api is rife with cruft and could use some rethinking. A lot of it was written around the assumption that fake api should be a thing. Since we deleted the fake api bits the code base could probably be simplified quite a bit.

This issue will certainly need some research before coding starts but some key points to keep in mind when starting on the refactor.

• Don't reinvent the wheel. Specifically in reference to decoding json into model structs. Poison already provides support for decoding json into structs. I don't think we need all of the decoder bits that we have now. We should leverage the facilities provided in poison. Additionally, do we really even need to return structs from the api? Would plain maps work just as well?
• Provide backwards compatibility. Since cog-api is pretty integrated into other projects we will probably need to provide a compatibility layer so things don't break and we can gradually upgrade all the necessary bits.
• Finally, and maybe most importantly, is this a critical library to maintain long term? The main use for the lib is to provide a consistent interface to the api in our other elixir projects. Currently that would be the web interface and cogctl. Eventually cogctl will be rewritten, most likely in Go or a similar language. This lib would then only be used by the webui. At that point would it be better to just role this functionality in with the webui?

Copied from original issue: operable/cog#1190

[christophermaier]

Update: cogctl has been rewritten in Python now, meaning that the only consumer of this code is the web UI.