Replacement of a specific Gluster node

[JohnStrunk]

Describe the feature you'd like to have.
It should be possible to remove or replace a specific Gluster pod, maximally preserving affected data's resiliency.

What is the value to the end user? (why is it a priority?)
In certain deployment scenarios, it may be necessary to decommission an admin-specified Gluster node. Examples include:

• In a deployment using DAS for Gluster bricks, the hosting server may need to be retired (hardware failure, lease expiration, etc).
• For network-based storage, the backing storage system may need to be replaced/retired

How will we know we have a good solution? (acceptance criteria)

• A particular Gluster pod instance can be targeted for decommissioning
• Bricks are migrated off of the pod prior to it being taken offline
• Once empty, the operator destroys the pod and associated South storage
• Operator adjusts cluster sizing as necessary to account for the loss of the node (i.e., for fixed node count clusters, "manual mode", a new node would be created).

Additional context
Requires state machine #17