Consider vendoring dependencies

[matwey]

Hello,

go get does just perfect when the recent version of influxdb is built.
But if somebody wants (for some reason) to build some specific old influxdb version from the sources, or somebody does git bisect, then influxdb code base may appear to be inconsistent with the dependencies (which are taken from master by go get). This may lead either to build failures or behaviour bugs.

[1] https://golang.org/s/go15vendor

[tinco]

This issue should receive high priority, as it is InfluxDB builds are not reproducible, and it might lead to strange behaviour of tagged releases.

Today my team was debugging an issue with clustering on 0.10. We figured we would check InfluxDB out from git, using the 0.10 branch, add some log statements and compile and run that in our test environment.

What we found was that the '0.10' we built had a new bug that totally prevents clustering from working at all. Anytime we add a second node to the cluster it says: "leadership lost while committing log", an error that comes from raft. Surprised at the difference in behaviour between our 0.10 and the 0.10 that is in Debian we looked at the dependencies and see that they are not constrained at all.

That means that any build of InfluxDB on a new machine just builds master of hashicorp/raft, which does not seem to have any structured release scheme at all. The hashicorp/consul project seems to acknowledge this as they have a build system that forces their builds to run on a specific commit of raft.