Share migration

Share migration is a feature discussed during Kilo midcycle meetup that proposes being able to move shares from backend to backend.
Upon implementing Share Migration, the Share re-type use case can be implemented, using Migration.
After some study on possible issues when migrating shares, a few limitations have been listed:
- Users will always be disconnected at some point during migration, they will need to remount the share.
- Preferably, a share should be made read-only prior to migration so users can continue using it during migration, this is a reasonable way to deal with huge shares. Changing to read only may cause a disconnect.
- Regarding Share metadata, it may either be chosen to be preserved or not. If chosen to be preserved, the following restrictions apply:
  - Share protocol should not change.
  - Security Services should be taken into account, as moving a Share that relies on a Security Service to another backend may render the Share useless unless the backend is able to register to the same Security Service. For this, Security Services should be advertised in “Capabilities”.

Implementation details:
So far, 2 approaches have been suggested:
1 - delegate to driver: this is a very optimized but restricted approach. The driver may be able to perform migration in a more efficient way if it understands the destination backend. A model update should be returned by the driver after the migration.
2 - managers coordinate, delegates some tasks to drivers: This approach will create a new share on destination host, mount both exports from the manila node, copy all files and then delete the old share. This approach should work for any driver that implements some methods necessary to help the migration process, such as:
  - changing the source share to read-only so users are less impacted by migration.
  - mounting/unmounting exports with specific protocols.

In order for approach 2 to work, every driver during server_setup method must create a port that allows connectivity between the share server and manila node.

Implementation should be a code that attempts approach #1, then #2 if unsuccessful, and should be minimally affected by Driver modes setting.