Add `xenorchestra_vdi` resource

[ddelnano]

This PR resolves #193. There is still more work to be done, but opening this up to review an early version of it and receive feedback on it.

This also provides the groundwork for the XO client package to work with the new XO rest api.

Todo

• [ ] ~Allow using an iso from a remote URL~
  • The http terraform provider is close to supporting downloading binary files (https://github.com/hashicorp/terraform-provider-http/pull/158). I'd prefer to help merge that rather than reimplementing something similar in the XO provider
• [x] Determine whether to support vdh VDIs on initial iteration -- decided to skip for now
• [x] Write resource documentation
• [x] Implement and test that client tls insecure settings work for both websocket and rest API
  • Unable to test that tls insecure setting works due to my environment having an expired cert but InsecureSkipVerify should be properly set.
• [x] Move iso file to git lfs

Testing

• [x] New acceptance tests pass
• [x] make testacc passes

  
  ddelnano@ddelnano-desktop:~/go/src/github.com/ddelnano/terraform-provider-xenorchestra$ make ci
  TF_ACC=1 ~/code/gotestsum/gotestsum --rerun-fails=3 --rerun-fails-max-failures=1000 --packages='./...' -- ./... -parallel 5 -v -count=1 -timeout=40m -sweep=true
  ∅  .
  ✓  xoa/internal (32ms)
  ✓  xoa (36m29.102s)

=== Skipped === SKIP: xoa TestAccXenorchestraVm_createVmThatInstallsFromTheNetwork (0.00s) resource_xenorchestra_vm_test.go:461: For now this test is not implemented. See #156 for more details

DONE 88 tests, 1 skipped in 2192.009s

[ddelnano]

As for use cases for VHD, I personally don't use that at all. Imho it would be more useful to support qcow2 images.

@4censord are you suggesting some type of qemu-img conversion for using VHD? Citrix Hypervisor / XCP-ng don't support qcow2 do they?

[ddelnano]

At this point the PR is ready to be merged. The later remote file support will be followed up on as mentioned in more detail here.

[olivierlambert]

Until SMAPIv3 is production ready, there's no support for qcow2. And when it will, it will depends on the SR type you are in (since SMAPIv3 will allow us to create any kind of SR driver supporting any kind of "way to store" VM disks)

[4censord]

As for use cases for VHD, I personally don't use that at all. Imho it would be more useful to support qcow2 images.

@4censord are you suggesting some type of qemu-img conversion for using VHD?

I didn't articulate well enough what i meant.

Afaik xcp-ng supports import of raw and vhd type images. Many cloud-ready images from upstream are provided in qcow2 format. Conversion is rather easy, qemu-img convert img.qcow2 img.raw, but is still a step to be done manually.

If either Xo or the provider would support converting from qcow2 to raw, that would eliminate this manual step.

As for use cases for vhd images: Same story of "some images might be VHD" so if we can support them that's great.

As far as I understood the provider just needs to set the parameters correctly, and shouldn't need to parse the vhd at all.