specs-go/round_trip_test: Add round-trip testing for the config

[wking]

To make sure the Go structs can accurately transport known-good configurations.

Also use a pointer for Process.ConsoleSize to avoid:

$ go test ./round_trip_test.go
--- FAIL: TestConfigRoundTrip (0.00s)
    --- FAIL: TestConfigRoundTrip/config_1 (0.00s)
        round_trip_test.go:32: failed to round-trip:
                {"ociVersion":"1.0.0","platform":{"os":"linux","arch":"amd64"},"process":{"consoleSize":{"height":0,"width":0},"user":{"uid":1,"gid":1},"args":["sh"],"cwd":"/"},"root":{"path":"rootfs"}}
FAIL
FAIL    command-line-arguments  0.003s

Background on this in golang/go#11939.

[wking]

The less contentious parts of this have been spun off into #791 and #792. Probably look at those first.

I'll rebase this one on top once they are dealt with, and we can decide if there's anything else in here worth keeping or give reasons for rejecting any remaining changes.

[tianon]

I think this is ready for the mentioned rebase? I'm personally pretty indifferent on the change either way, and don't think it really warrants holding up 1.0 (seems like a good way for us to verify our work is self-consistent, but not a strict requirement).

[wking]

On Wed, May 10, 2017 at 09:37:12PM -0700, Tianon Gravi wrote: I think this is ready for the mentioned rebase?

Rebased with 750562b → 05415d4. I think we still want the UID and GID pointers from 05415d4. My (possibly muddled) recollection from the 2017-05-09 meeting [1] is that @crosbymichael preferred “no pointers if a property is REQUIRED on any platform”, even though that means that you can't reliably use Go's default JSON serializer. For example, the Go types in master will currently inject: "uid":0,"gid":0 into process.user if you use Go's JSON serializer even though those fields are not defined for Windows. I'd offered to pull that commit out into its own PR, where @crosbymichael could reject it (and give his motivation in his own words), but he didn't seem to keen on that either. If my understanding of his preferred policy is accurate and sounds appealing to other maintainers, I can submit a PR updating [2] (although it may be faster if someone who personally holds that position works up the style PR).

… and don't think it really warrants holding up 1.0…

Right. And we can always cut 1.0.1 with improved Go types for consumers handling the 1.0 Markdown spec. But if we can form a consensus on this either way before 1.0, I think we should do that and avoid risking a post-1.0 fixup. [1]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-05-09-20.07.log.html#l-71 [2]: https://github.com/opencontainers/runtime-spec/blob/1259a08e003658f8c4094a6bbc9f52aee29c95df/style.md#optional-settings-should-not-have-pointer-go-types

[wking]

@mrunalp, I think you were going to add a comment (or file a style.md PR?) about the pointer pattern so I don't mis-paraphrase?