The project does not need to be retreived from the db every time
it is queried for data. However, it does need to be updated whenever
a target is initialized from the project (eg. an upsert machine
action happens). This is because upserting a target will update the
associated project. Leaving the core.Project with stale data
unless it is refreshed.
It is not guaranteed which project is ever being used. So whenever
some project property is queried make sure to refresh the project
by getting the latest one from the database.
Some commands like `vagrant init` and `vagrant box` should be able to
run successfully without a full Project available in VAGRANT_CWD (in
other words, they don't require that a valid Vagrantfile be available.)
Thus far we've been assuming that a Project is available when
dispatching commands, which mean that commands of this nature weren't
working.
Here we make the Basis available to serve as an alternative client to
Vagrant::Environment::Remote such that it can be instantiated and passed
through to commands. This required some changes to Environment::Remote
to make its interactions with the client more defensive, but we manage
to avoid needing to make any changes to the normal legacy codepaths.
Having these objects populate their seeds during `Run` was too late for
those values to show up in command plugins, which would be seeded with
empty args instead.
h/t @chrisroberts for the debugging help and fix suggestion!
* 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
```
