Remove bosh_backup.tgz after bat test
Remove references to vCloud gems

[finishes #52098303]

Removed gems can now be found at cloudfoundry/ruby_vcloud_sdk and
cloudfoundry/bosh_vcloud_cpi. The gems have been repackaged as the gems
that were removed were holding back some of our dependencies.
[agent] Post prepare network changes should restart agent [fixes #52275897]

When there's a network change on an existing vm, director sends a prepare_network_change message to the vm
agent. After agent replies to director with a `true` message, the post_prepare_network_change method is called
(via EM callback).

The post_prepare_network_change  method will delete the udev network persistent rules, delete the agent settings
and then it should restart the agent to get the new agent settings (set by director-cpi). For a simple network
change (i.e. dns changes) this is enough, as when the agent is restarted it will apply the new network settings.
But for other network changes (i.e. IP change), the CPI will be responsible to reboot or recreate the vm if needed.
[director] Reorder instance update steps [fixes #52547427]

When updating an instance, sometimes we need to recreate the vm
(eg when IP changed). If the job has a persistent disk, that means
attaching a disk to the vm, detaching the disk, recreate the vm, and
reattach the disk again.

In this commit we are reordering the update steps, so the persistent
disk step is executed after any network change. In this way, we are
only attaching the disk once.

It also fixes a bug that prevented to reattach the disk when the vm
was recreated.
User must provide a password again for bosh ssh

This reverts commit 6191c586cbb52b5a84381314fb641c8c9dfc0a02.

This commit needed to be reverted because it meant that users who were
using the latest version of the CLI but were using an older version of
the stemcell/agent were unable to `sudo su` on any of their BOSH VMs.
This was caused by the new CLI not prompting for a password and the old
stemcells not including the new BOSH user in the NOPASSWD sudo group.

A workaround is to use the `vcap` user for now.