vendor with go mod

Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>

vendor/github.com/google/go-cmp/README.md

@@ -1,44 +0,0 @@
-# Package for equality of Go values
-
-[![GoDoc](https://godoc.org/github.com/google/go-cmp/cmp?status.svg)][godoc]
-[![Build Status](https://travis-ci.org/google/go-cmp.svg?branch=master)][travis]
-
-This package is intended to be a more powerful and safer alternative to
-`reflect.DeepEqual` for comparing whether two values are semantically equal.
-
-The primary features of `cmp` are:
-
-* When the default behavior of equality does not suit the needs of the test,
-  custom equality functions can override the equality operation.
-  For example, an equality function may report floats as equal so long as they
-  are within some tolerance of each other.
-
-* Types that have an `Equal` method may use that method to determine equality.
-  This allows package authors to determine the equality operation for the types
-  that they define.
-
-* If no custom equality functions are used and no `Equal` method is defined,
-  equality is determined by recursively comparing the primitive kinds on both
-  values, much like `reflect.DeepEqual`. Unlike `reflect.DeepEqual`, unexported
-  fields are not compared by default; they result in panics unless suppressed
-  by using an `Ignore` option (see `cmpopts.IgnoreUnexported`) or explicitly
-  compared using the `AllowUnexported` option.
-
-See the [GoDoc documentation][godoc] for more information.
-
-This is not an official Google product.
-
-[godoc]: https://godoc.org/github.com/google/go-cmp/cmp
-[travis]: https://travis-ci.org/google/go-cmp
-
-## Install
-
-```
-go get -u github.com/google/go-cmp/cmp
-```
-
-## License
-
-BSD - See [LICENSE][license] file
-
-[license]: https://github.com/google/go-cmp/blob/master/LICENSE

vendor/github.com/google/gofuzz/.travis.yml

@@ -0,0 +1,13 @@
+language: go
+
+go:
+  - 1.4
+  - 1.3
+  - 1.2
+  - tip
+
+install:
+  - if ! go get code.google.com/p/go.tools/cmd/cover; then go get golang.org/x/tools/cmd/cover; fi
+
+script:
+  - go test -cover

vendor/github.com/google/gofuzz/CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# How to contribute #
+
+We'd love to accept your patches and contributions to this project.  There are
+a just a few small guidelines you need to follow.
+
+
+## Contributor License Agreement ##
+
+Contributions to any Google project must be accompanied by a Contributor
+License Agreement.  This is not a copyright **assignment**, it simply gives
+Google permission to use and redistribute your contributions as part of the
+project.
+
+  * If you are an individual writing original source code and you're sure you
+    own the intellectual property, then you'll need to sign an [individual
+    CLA][].
+
+  * If you work for a company that wants to allow you to contribute your work,
+    then you'll need to sign a [corporate CLA][].
+
+You generally only need to submit a CLA once, so if you've already submitted
+one (even if it was for a different project), you probably don't need to do it
+again.
+
+[individual CLA]: https://developers.google.com/open-source/cla/individual
+[corporate CLA]: https://developers.google.com/open-source/cla/corporate
+
+
+## Submitting a patch ##
+
+  1. It's generally best to start by opening a new issue describing the bug or
+     feature you're intending to fix.  Even if you think it's relatively minor,
+     it's helpful to know what people are working on.  Mention in the initial
+     issue that you are planning to work on that bug or feature so that it can
+     be assigned to you.
+
+  1. Follow the normal process of [forking][] the project, and setup a new
+     branch to work in.  It's important that each group of changes be done in
+     separate branches in order to ensure that a pull request only includes the
+     commits related to that bug or feature.
+
+  1. Go makes it very simple to ensure properly formatted code, so always run
+     `go fmt` on your code before committing it.  You should also run
+     [golint][] over your code.  As noted in the [golint readme][], it's not
+     strictly necessary that your code be completely "lint-free", but this will
+     help you find common style issues.
+
+  1. Any significant changes should almost always be accompanied by tests.  The
+     project already has good test coverage, so look at some of the existing
+     tests if you're unsure how to go about it.  [gocov][] and [gocov-html][]
+     are invaluable tools for seeing which parts of your code aren't being
+     exercised by your tests.
+
+  1. Do your best to have [well-formed commit messages][] for each change.
+     This provides consistency throughout the project, and ensures that commit
+     messages are able to be formatted properly by various git tools.
+
+  1. Finally, push the commits to your fork and submit a [pull request][].
+
+[forking]: https://help.github.com/articles/fork-a-repo
+[golint]: https://github.com/golang/lint
+[golint readme]: https://github.com/golang/lint/blob/master/README
+[gocov]: https://github.com/axw/gocov
+[gocov-html]: https://github.com/matm/gocov-html
+[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
+[squash]: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits
+[pull request]: https://help.github.com/articles/creating-a-pull-request