Update Vagrant box to include VBoxGuestAdditions pre-installed

[mloskot]

For better end-user experience, if possible, any Vagrant box released by/for SWDT should be pre-provisioned with the guest additions and, ideally, from the latest VirtualBox at time of box creation (I assume we will version the box and release updates as it is common for Vagrant boxes).

Currently, this post-boot phases presented below can take even 15 minutes to get from the No Virtualbox Guest... to completing the vagrant up on a very decent workstation

For reference, I'm testing the plain box 'outside' the SWDT workflow using the following Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
require 'yaml'

Vagrant.configure(2) do |config|
  config.vagrant.plugins = ["vagrant-vbguest"]

  config.vm.define :win2019 do |vb|
    vb.vm.box = "sig-windows-dev-tools/windows-2019"
    vb.vm.box_version = "1.0"
    vb.vm.communicator = "winrm"
    vb.vm.guest = :windows
    vb.vm.host_name = "win2019"
    vb.vm.provider :virtualbox do |vb|
      vb.cpus = 2
      vb.memory = 8192
      vb.gui = false
      # Explicitly  Windows guest version and type
      vb.customize ["modifyvm", :id, "--ostype", 'Windows2019_64']
      # Explicitly use Windows guest default graphics controller
      vb.customize ['modifyvm', :id, '--graphicscontroller', 'vboxsvga']
      # Explicitly disable unnecessary features for better performance
      vb.customize ["modifyvm", :id, "--accelerate3d", "off"]
      vb.customize ["modifyvm", :id, "--accelerate2dvideo", "off"]
      vb.customize ['modifyvm', :id, '--clipboard', 'disabled']
      vb.customize ['modifyvm', :id, '--draganddrop', 'disabled']
      vb.customize ['modifyvm', :id, '--vrde', 'off']
    end
    vb.vm.synced_folder ".", "/vagrant"

    vb.winrm.username = "vagrant"
    vb.winrm.password = "vagrant"
  end
end

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mloskot]

I'm closing this as replaced by the currently ongoing SWDT CLI sub-project

• 278 (see #277 for context)