feat: Add TOML support for config files

[fmartingr]

Summary

This pull request adds TOML support for config files.

The ReadFromJSON function has been refactored into a unified ReadFrom with the same signature that determines the filetype by the extension the file has, if the extension is .toml a TOML decoder is used, following with JSON by default.

Code chagues

• Created a Decoder interface that we can use to simplify the unmarshalling logic in the code (try to decode, search for fallback, etc). Now we just pass the Decoder (or DecoderFactory) around and the rest of the logic is the same for all decoders.
• Implemented JSONDecoder and TOMLDecoder (from json.Decoder and toml.Decoder) since their signatures are different and also to allow TOML to show up better errors on decoding failures.
• Main point is the "new" ReadFrom method that should take care of everything.
• It defaults to JSON so all regular usage should keep working as usual

Potential improvements

I focused on the Decoding part only, but if we plan to use it also as a encoder (to generate config files) we need to improve the data structure, interfaces and names around. It shouldn't be much but something to take into consideration.

I like to have "Codec" interfaces that take care of encoding/decoding around and create implementations for whatever thing I want to support, to I would go in that direction. Maybe in another PR if this one gets in.

Why

TOML files are way more readable for the end user, and we can put comments in the file for explanation of fields, better sort keys, etc.

Even better could be using the TOML's library capabilites to add comments on TOML files. I potentially see this in a way that:

• The data structure is defined with all necessary fields and comments
• Sample files are rendered directly from the structs
  • Creating the file automatically means we would lose manual organization, like in the deployer.sample.toml file I commited to this branch where I grouped settings. But that can be solved by nesting structs by topic.
• A CI step (lint) can create sample files from the configuration structs and check if the ones match with the code, ensuring that they are always up to date. This would lead to the data structures being the source of truth for the configuration while providing documentation right in the TOML files.

Test run

Performed a trial deployment with config and deployer TOML files. Didn't test all commands manually.

Ticket Link

--

[agnivade]

Neat work. Left some comments.

[agarciamontoro]

This looks great! Thank you so much for putting the effort into implementing this <3 Just a couple of nits before approving.

[agarciamontoro]

Looks great, thank you!