Support for pre-configuring communicator transports (SSH or WinRM) via init_script setting

[maxlinc]

This adds support for an init_script setting. The init_script is a small script that run before the Vagrant communicator connects to run Vagrant provisioners. The use of init_script should be avoided whenever possible, since a normal provisioner is more portable and easier to troubleshoot when something goes wrong (since Vagrant will capture the results), but the use of an init_script is sometimes needed to configure the communication protocols for communication with Vagrant.

Two known cases that require an init_script (in order to work with Rackspace base images rather than having to create custom images):

• Disabling sudo requires tty for the RHEL family of Linux distros (RHEL, Fedora, Centos). If it's not enabled it causes problems with rsync (Rsync tty issues #115).
• Enabling and securing WinRM on Windows machines. WinRM is the "Windows equivalent of SSH" (although it doesn't tunneled protocols for file transfer) but is not enabled on base images.

The intention of init_script is the same for SSH & WinRM - it after the server is booted but before we tell Vagrant the machine is ready to provision. However, the implementation is slightly different for the two:

• If the transport is WinRM, then we send the script via server personalities to "C:\cloud-automation\bootstrap.cmd", is run when the server starts. This is necessary because we usually can't connect to WinRM at all by default. It does mean we can't capture the output or see if the script failed.
• If the transport is SSH, then we connect and run the script via SSH. So the script can include customizations that will apply to future SSH connections (including protocols tunneled over SSH, like rsync), but assumes that a basic connection is working. The output can be captured.

It might be possible to run the init_script for SSH via cloud-init, so it would be more consistent with how init_script works for Windows, but that's more complicated, harder to troubleshoot, and I'm not sure cloud-init is supported on all images. So I'm not sure its worth it until there's a known use-case.

[maxlinc]

This is basically an alternate solution for #120, which adds a way to deal with the requiretty issue (#115) while also adding support for Windows.

This is also a lower level solution - which is good because the scripts can be customized (e.g. my WinRM solution uses self-signed certificates; some organizations might want to install a custom CA instead), but we might want higher-level options or auto-detection to decide if a commonly used init_script is needed, like the use_tty_workaround setting from #120.

I think a good option would be to use strings as a script, but to look up symbols from a collection of common scripts that are shipped with the gem. So you could use settings like:
init_script = :require_tty_workaround or init_script = :enable_winrm.

@smashwilson @mdarby: Can you review and also let me know about the comment above?

[smashwilson]

☝️ I'd say, keep it as letting the API validate the script length. That way we're insulated from configuration or account changes that would alter the limits. There would be nothing more annoying than having your account adjusted to allow a larger init script, but have Vagrant shut you down before it even tries the call.

[maxlinc]

That's the problem, the API doesn't validate the script length. It does't fail either - it just ignores the script but boots the server.

In the case of WinRM it means it'll just hang waiting for a WinRM connection when the server isn't listening for WinRM.

[smashwilson]

Oh, I see. Well that's annoying. I'm not sure what a good solution for that is, then. 😒

[smashwilson]

@maxlinc Looks reasonable to me, modulo that comment typo.

[smashwilson]

Works for me. 🤘