Having the modules stored in `./vendor` causes issues with `go mod`.
Follow waypoint's convention to store in `./thirdparty` and grab
the same Makefile modifications to alert when the submodules need
to be initialized. Update generators to use new path.
* Populate push configs when parsing the vagrantfile
* Allow untyped configs to be shipped over GRPC
* In our demo plugin, walk the vagrantfile and snag the config
Example Vagrantfile that works with the demo plugin:
```ruby
Vagrant.configure("2") do |config|
config.push.define "myplugin" do |push|
push.coolkey = "coolvalue"
push.alist = ["so", "many", "items"]
push.ahash = { "hashkey" => "hashvalue" }
end
end
```
This uses the new Push plugin support added to the plugin SDK in https://github.com/hashicorp/vagrant-plugin-sdk/pull/106 to make the following changes:
* The plugin manager on the Go side now registers push plugins
* The the _remote_ plugin manager on the Ruby side now calls over to
the go side to get push plugins
* All the wiring is hooked up such that when a push plugin is replaced
with its remote GRPC-client-wielding equivalent, the messages are
ferried around.
You want to know something silly? There are multiple versions of
go-bindata floating around in the world, and they have different
features and flags.
This httpfs package was written with
https://github.com/go-bindata/go-bindata and uses the -fs flag. Most
everyone else (nixpkgs, homebrew) seems to have moved over to this fork
https://github.com/kevinburke/go-bindata, which does not have that
feature.
Run `go generate` with this installed and you'll get an error like `flag
provided but not defined: -fs`.
It looks like `httpfs` is the odd one out here, and it's not used
anywhere I can find either here or waypoint, so let's just remove it so
we can `go generate` cleanly with the version of go-bindata that most
people are using.
The uuid is the public identifier vs the resource id which should
be for internal operations.
The target uuid should correspond to the machine id (given by
the provider)
