Go module/1.11.x support, vendored deps, cttestsrv api fixes.

[cpu]

• Fixes the cttestsrv API breakage with Trillian master from time source refactoring.
• Updates the project/CI to use Go 1.11.x
• Configures a ct-woodpecker module
• Vendors dependencies[0]
• Removes errcheck[1] from CI
• Updates CI to use vendored deps throughout
• Fixes a few typos flagged by Goreportcard

Resolves #72 and #73 and fixes CI.

[0]: Notably this pins Trillian to d0c8d5f - the tip of master at the time of writing. We're using changes that aren't in the latest v1.2.1 tag. Similarly, Trillian at tip of master requires us to pin golang/protobuf at 1d3f30b - the tip of master for that project at the time of writing. Trillian is using changes in this project that aren't in the latest v1.2.0 tag.

[1]: Errcheck doesn't work with Go modules and our vendored deps. Adding it back is blocked on kisielk/errcheck#155 Personally I think the stability improvements of vendored dependencies merits removing errcheck from Travis and the cron builds. We do still get errcheck coverage per-PR with GolangCI.

[coveralls]

Pull Request Test Coverage Report for Build 484

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 67.515%

---

Totals
Change from base Build 365:	0.3%
Covered Lines:	769
Relevant Lines:	1139

---

💛 - Coveralls

[jsha]

I think go get with GO111MODULE=off still fetches dependencies, since that's what go get has always done, right? If we wanted to segregate the dependencies of these tools I think we'd need to set GOPATH to some alternate path.

[cpu]

I think go get with GO111MODULE=off still fetches dependencies, since that's what go get has always done, right?

It downloads the dependencies needed by these tools, into the default $GOPATH ($HOME/go) and that's what I wanted.

I didn't make it very clear in my comment but with GO111MODULE=on running go get github.com/cpu/some-tool-we-need in the ct-woodpecker project root with Go 1.11+ would download all of the dependencies for ct-woodpecker and some-tool-we-need. I don't really understand why that is the case but what I wanted was to just let a default GOPATH be initialized with the various utils we need and their deps, without fetching ct-woodpecker's deps. I also didn't want to vendor the tools in ct-woodpecker.

Does that make sense? I could try to better capture this in the comment.

[jsha]

Ohhh I misread "project dependencies" to mean the opposite - the dependecies of cover and goveralls. I think if you just replace "project" with "ct-woodpecker" it becomes clear (though I also don't understand why Go has the behavior you described)

[cpu]

I think if you just replace "project" with "ct-woodpecker" it becomes clear

Fixed in 55860dc

I also don't understand why Go has the behavior you described

Thinking about it more it happens because running go get in a module enabled project with GO111MODULE=on means you want go get to be updating go.mod to track the new dependency. I think at the same time it adds the new dependency it fetches the others. I thought about trying to run the go get outside of the project dir instead but while researching the answer to this I see that would have caused its own unique problem specifically because go get would have failed to find the go.mod to update: https://github.com/golang/go/wiki/Modules#why-does-installing-a-tool-via-go-get-fail-with-error-cannot-find-main-module