Remove vendor from git

Previously we saved the vendor tree in version control, making any
commit that changed a dependency rather large.
Go Modules gives us most of the advantages of vendoring except that if a
dependency which is not stored on the proxy is deleted we would lose
access to it.
For now, we can remove the vendor tree and when we get CI working again
we can possibly generate and save the vendor tree as a build artifact.

Signed-off-by: Sam Whited <sam@samwhited.com>

1 files changed, 0 insertions, 12 deletions

diff --git a/vendor/github.com/smartystreets/assertions/CONTRIBUTING.md b/vendor/github.com/smartystreets/assertions/CONTRIBUTING.md
deleted file mode 100644
index 1820ecb..0000000
--- a/vendor/github.com/smartystreets/assertions/CONTRIBUTING.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Contributing
-
-In general, the code posted to the [SmartyStreets github organization](https://github.com/smartystreets) is created to solve specific problems at SmartyStreets that are ancillary to our core products in the address verification industry and may or may not be useful to other organizations or developers. Our reason for posting said code isn't necessarily to solicit feedback or contributions from the community but more as a showcase of some of the approaches to solving problems we have adopted.
-
-Having stated that, we do consider issues raised by other githubbers as well as contributions submitted via pull requests. When submitting such a pull request, please follow these guidelines:
-
-- _Look before you leap:_ If the changes you plan to make are significant, it's in everyone's best interest for you to discuss them with a SmartyStreets team member prior to opening a pull request.
-- _License and ownership:_ If modifying the `LICENSE.md` file, limit your changes to fixing typographical mistakes. Do NOT modify the actual terms in the license or the copyright by **SmartyStreets, LLC**. Code submitted to SmartyStreets projects becomes property of SmartyStreets and must be compatible with the associated license.
-- _Testing:_ If the code you are submitting resides in packages/modules covered by automated tests, be sure to add passing tests that cover your changes and assert expected behavior and state. Submit the additional test cases as part of your change set.
-- _Style:_ Match your approach to **naming** and **formatting** with the surrounding code. Basically, the code you submit shouldn't stand out.
-  - "Naming" refers to such constructs as variables, methods, functions, classes, structs, interfaces, packages, modules, directories, files, etc...
-  - "Formatting" refers to such constructs as whitespace, horizontal line length, vertical function length, vertical file length, indentation, curly braces, etc...