Change error code when vDPA is unsupported

We had specified that we would return HTTP 403 (Forbidden) in the event
that a unsupported operation was requested on an instance with one or
more vDPA interfaces attached. This was chosen due to us already using
this code for unsupported operations with cyborg accelerators. However,
HTTP 403 (Forbidden) isn't a great choice for this, as it suggests
issues with authorization as opposed to a request the server simply
can't support. HTTP 409 (Conflict) isn't much better, but it does avoid
confusion with policy issues and aligns us with two other existing
examples: unsupported operations on instances with vTPM devices and
instances with SEV enabled.

Change-Id: Ia5d77416b497ef04fb915841b8cdf300230ff00c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

specs/wallaby/implemented/libvirt-vdpa-support.rst

@@ -36,8 +36,8 @@ the guest to use standard virtio drivers instead of a vendor specific driver.
   advantages of VDPA based networking over sriov is the ability to abstract the
   device state from the VM allowing transparent live migration via a software
   fallback. Until that fallback is implemented in QEMU, live migration will be
-  blocked at the api via a 403 error response so that we can enable it without
-  a new micro-version.
+  blocked at the api via a HTTP 409 (Conflict) error response so that we can
+  enable it without a new micro-version.
 
   As Open vSiwtch is currently the only control plane capable of managing VDPA
   devices and since that requires hardware offloads to function this spec
@@ -266,3 +266,5 @@ History
      - Description
    * - Wallaby
      - Introduced
+   * - Wallaby
+     - Updated to reflect changes to HTTP error codes