Boolean types (and possibly a few others) are returned as wrapper
classes when coming out from proto mapping; these need to be unwrapped
otherwise the caller who is expecting a nice clean boolean value ends up
with an icky protobuf class.
This fixes the shell provisioner, which relies on a communicator
receiving a settings hash `{error_check: false}` for a command that
usually fails but it sent just in case before provisioning starts.
* 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.
The exception logger no longer logs errors. Instead it transforms
the errors into a grpc friendly format. The exception that would
have been logged at this point gets logged when the task completes.
The local-exec push strategy was assuming it was running from a CLI and
so it wouldn't be a big deal for it to straight up `exec` and replace
its running with the user command. That command will just do its thing
and we want the exit code for the CLI command to match anyways, right?
Sure that works for a shell, but in a GRPC server setting it's decidedly
Not Cool to suddenly swap out the running process!
As you can imagine - the effect of doing this was all sorts of broken
pipes and unexpected EOFs and a very confused @phinze.
Luckily we had a subprocess strategy sitting right there for Windows
compat, so it was just a matter of switching to that in the server
context as well. Long and winding debugging process; simple fix;
just another classic!
