v2: add cmds for toml-test integration

[moorereason]

It would be useful to pass the tests in the toml-test project. We need a cmds similar to toml-test-decoder and toml-test-encoder.

I hacked up a partial implementation using some of the BurntSushi json tagging code. It works with the exception of datetime json tagging. With my tests, v2 decoder results: 237 passed, 47 failed (but 3 of the failures are related to json tagging issues in the integration).

[pelletier]

We used to have a binary to be compatible with with toml-test. However I replaced it with a program that generates Go test files for those: #264. I still like its approach for portable testing.

Maybe we should re-gen the tests periodically so that we can catch new stuff?

[moorereason]

I'm wanting to use the binary API to compare various decoders' handling of fuzzed input. Should give more corner cases not in the existing toml-test suite. Already found one bug in BurntSushi/toml.

[pelletier]

That's cool! Sounds like we can have both: binaries to test encoding/decoding and generating tests (to avoid having BurntSushi/toml as a dependency or resorting to a script).

[moorereason]

As a follow-up to this discussion, I've pushed up my proof-of-concept fuzzing setup: tomlfoolery. The only two implementations I'm aware of for testing the framework are go-toml and BurntSushi.

There are bugs in each package that the fuzzer keeps finding, so it's tricky to keep fuzzing once a failed case is found. I'm still learning how to use fuzzing, so I'm sure there's more that could be done to make it more useful.

[pelletier]

Neat! I'm happy to prioritize working on defects found by fuzzing if it helps.

[moorereason]

Most of what is found today is covered by the toml-test suite. Once those all pass, it will get more interesting.