GitLab

It's small, it's simple, and it's already widely used as part of unixfs.
So there's no reason it shouldn't be part of go-ipld-prime.

The codec is tiny, but has three noteworthy parts: the Encode and Decode
funcs, the cidlink multicodec registration, and the Bytes method
shortcut. Each of these has its own dedicated regression test.

I'm also using this commit to showcase the use of quicktest instead of
go-wish. The result is extremely similar, but with less dot-import
magic. For example, if I remove the Bytes shortcut in Decode:

	--- FAIL: TestDecodeBuffer (0.00s)
	    codec_test.go:115:
	        error:
	          got non-nil error
	        got:
	          e"could not decode raw node: must not call Read"
	        stack:
	          /home/mvdan/src/ipld/codec/raw/codec_test.go:115
	            qt.Assert(t, err, qt.IsNil)

Begin using it in some parts of testing of schema parse&compile.
(I don't think I'll try to push all usage of go-wish over to quicktest
in one flurry of diffs right now.  But it might be future work.)

The breaking point is that asserting on lists of errors using go-wish
was starting to exhibit Weird behaviors for only *some* error types.
It's likely that this would be addressable using some kind of go-cmp
customization, but go-wish doesn't really expose that ability.
The quicktest library does.

Switching to quicktest also brings a bunch of other nice features
along with it, like stack traces and other forms of additional info.
The holistic feel of it is also pretty similar to go-wish (particularly
since https://github.com/frankban/quicktest/pull/77 ), so many things
should be easy to switch.  I suspect I might want some more checker
functions to assert on types... but those should be easy to add as
a third party, either as a go-cmp.Transformer or a qt.Checker (and
then we can work on upstreaming at leisure, if appropriate).

In this commit, I'm handling the error list situation using a
go-cmp.Transformer to stringify all the errors.  This means that the
error *types* aren't checked, which is definitely loses ditches some
information... but the upside is that its easy to use the tests to
check that the eventual string of the error message is human-readable.
In this API, I think that readability is the higher priority.

The common policy is to support the two latest versions of Go. Do that,
since our previous state meant a version of Go that's pretty old and
unused at this point.

Also simplify the travis yaml. First, GO111MODULE=on hasn't been needed
for a while, since it defaults to "on" if go.mod exists. We also don't
need redundant steps like "go mod download" or "go build"; "go test"
already does all of that for us. The "go fmt" check is also pointless,
as it only formats the code without actually complaining if it isn't
properly formatted.

Finally, update the Go version in go.mod to 1.14, since that's the
oldest version we test against and support at this point. This version
sets, for example, what language features we can use.

And, while at it, "go mod tidy".

Be aware I'm using the go mod files blindly, and actually testing and
developing using the git submodules.

I actually only wanted one update here -- the go-wish library bump,
for a specific new feature I wanted for some work on another branch --
but as long as I'm here, apparently all these bumps break nothing.