NetApp fix for vsadmin role failure for ssc

The ssc feature does not work with vserver admin
role. If the user is a vsadmin then he does cannot
use the ssc feature fully. This fix checks the access
and issues apis appropriately and also handles error
conditions.

Closes-Bug: #1253657

Change-Id: Ibc4409e5d5e6e36bba41e5f59dd94c05b87b1cde
(cherry picked from commit 20667f7d49eed88ddd528be73293a624b3af1ba0)
Update quota-set throw 500 error

The server doesn't check whether the parameter "quota_set" or
"quota_class_set" is in request
body.So the 500 error has been thrown.

We should catch the KeyError and transfer the KeyError to
400(HTTPBadRequest) instead of 500.

Closes-Bug: #1249971
(cherry picked from commit 2ed2f3aff8eee70e02eb995780af292057cfcad4)
Change-Id: I01260c77efa50324f3d203888689cdb1e94d2c21
VMware: Fixed upload-to-image for available volume

Cinder generally does not allow upload-to-image operation on a volume
that is 'in-use'. This can however be over-ridden using the '--force True'
flag. The VMware driver cannot support upload-to-image when the volume is
in-use. This is a restriction for the VMware driver alone. When the user forces
an upload on a volume that is 'in-use' the Cinder api layer sets the volume
status to 'uploading' and calls into the driver code to upload. In this
scenario the VMware driver needs to fail the operation.

The current driver code here does this check wrongly by looking for volume
status of 'in-use'. Fixing this check to identify an in-use volume correctly.

Fixes bug: 1237338

(cherry picked from commit a2b774c0ce2a1aaa9cdfc7d7c4c4d642f1bfc3d1)

Change-Id: If54edfdc242a7a1bff442b6bb4c5a9865eede1dc
Merge "VMware: Fixed upload-to-image for available volume" into stable/havana
Merge "NetApp fix for vsadmin role failure for ssc" into stable/havana
Merge "Update quota-set throw 500 error" into stable/havana
User a more accurate max_delay for reconnects

In an HA deployment, a 60 seconds delay between reconnects can be quite
problematic. This patch changes the delay calculation by setting the max
delay to 5s and by changing the way it is increased.

Unfortunately, this is one of the places where both our main drivers are
not consistent. Rabbit's driver uses configuration parameters for this
whereas qpid's driver has never had one. However, I would prefer not
adding configuration paremeters to qpid's driver for the following
reasons:

    1. Most of OpenStack services depend on the messaging layer, hence
    they need it to be available. A 5s delay seems to be reasonable and
    I could argue the need of tune it further. Although so frequent
    reconnects can add load to the network, that wouldn't be the main
    issue if one of the brokers go down.
    2. We're trying to move away from configuration options towards using
    transport URL. This path is still not clear and I would
    prefer avoiding adding new options until we clear it out.

Closes-bug: #1281148

Change-Id: I537015f452eb770acba41fdedfe221628f52a920
(cherry picked from commit 8b628d1e024f787dbb93d508117d9148388c0590)
Merge remote-tracking branch 'upstream/stable/havana' into stable/havana