New encoding layer

[sagikazarmark]

This PR adds an encoding layer to Viper, separating direct calls to encoding libraries to different packages and ultimately moving out most of the logic from the main Viper package.

The package implements the proposal from #888 with the exception of moving them out from the module to preserve backwards compatibility. That cannot happen in the v1 branch as it would be a breaking change, but introducing an encoding layer this way allows us to move things out of the module easily in the future.

Although this is a sane proposal and I believe it's the way forward, the abstraction is not perfect and we can already see some shortcomings:

• TOML does not support map[string]interface{} well (compared to JSON and YAML anyway), so it contains some conditional logic specific to that type.
• Many supported formats (INI, dotenv, Java properties) don't have a JSON/YAML style "unmarshal" API. In fact, some of them are completely different:
  • In case of dotenv, the env var names are generated by formatting the keys
  • In case of INI sections are created from keys

All this points towards a much higher level abstraction where we pass and return map[string]interface{} directly. The current implementation is a low level interface based on the Marshal/Unmarshal style of encoding/json.

Something like this would probably be better:

// Decoder decodes the contents of b into a map[string]interface{}.
type Decoder interface {
	Decode(b []byte) (map[string]interface{}, error)
}

// Encoder encodes the contents of v into a raw byte representation.
type Encoder interface {
	Encode(v map[string]interface{}) ([]byte, error)
}

There are also some other missing pieces from this PR:

• Proper tests for the different codecs (currently we rely on Viper's tests which are...not necessarily good)
• Some codecs might have additional config options

I'm not sure whether this change should make its way to Viper as it is. On one hand it would be nice to start experimenting, on the other hand this is not a perfect solution and will require some changes for the long-term. I'll leave this PR here for now, wait for some potential feedback and merge it if it still feels right after a few days/weeks.

[bogdandrutu]

Not sure if matters, but can use sync.Map to avoid explicitly synchronize access to the map.

[sagikazarmark]

Hm, yeah, interesting idea. For now, I think type safety is more important than performance, especially since this mutex won't be locked more than 5-10 times during an application's lifecycle. But I will certainly play with it in the next round of changes (this is not the final form of the encoding package).

Thanks!

[chrisdoherty4]

Would defining type Key string and replacing format string with format Key both here and in the Decode() method be appropriate?

It's a trivial change, but cognitively it highlights the relationship between the parameters across the different methods while still allowing consumers to use strings.

Ditto for the encoder.

[sagikazarmark]

I'm not sure it'd be. What does Key mean? Format I understand.

[chrisdoherty4]

Perhaps Key is the wrong type name - perhaps type Format string is better. The crux of the suggestion is to just better highlight the relationship across methods rather than relying on variable names; perhaps it's unnecessary though.

[sagikazarmark]

I'm going to merge this PR for now. I've created a note in the Viper 2 board with the next steps (will probably convert it to an issue).