Check volume_backend in retype

Check volume_backend in retype

The retype command will always attempt a call
to the driver.retype method.  In *most* cases this
will hit the default impl which returns False because
most drivers don't implement any retype (most, a few do).

The problem is that the drivers that do implement this in
most cases will iterate through the settings and just make
the changes that are valid and ignore the rest, and then
return True. I think this is "ok" for the drivers to do,
drivers should be allowed to be somewhat dumb WRT Cinder
state management and placement info.  If we give them an
invalid command (which we're doing here) then it's on us
higher up the chain IMO.

The result is that for example if you're trying to retype
from backend-a to backend-b and backend-a implements retype
it can return True telling the manager that the volume was
succesfully retyped, even when it wasn't.

There's a lot of confusion around this bug, YES the
filter scheduler is used to determine if the retype is
valid and to what host.  That's not the issue, the issue
is that regardless of the source and destination host settings
that are provided from the filter-scheduler, we always make the
call to the driver, introducing the opportunity for a false
success status being reported back.

This patch adds a very simple check between the source and
destination host settings as provided by the scheduler and in
the case that the two are "different"(not including pool designations)
we skip calling the driver.retype method altogether and fall through
to the migrate process.

This introduces a new hosts_are_equivalent method in
cinder.volume.utils

Change-Id: Idfd7dfa2284fcea66cf23c4273efda61ee8f7eba
Closes-Bug: #1452823