Introduce distribution zone manager for the purposes of zones configuration

Motivation

Distribution zones manager is an ignite component that is responsible for both zones configuration(create/update/drop) and dataNodes calculation that is triggered by corresponding topology and zone modification events.

Within the scope of current ticket it's expected that DistributionZoneManager will be introduced with an internal API to create, drop and alter distribution zones.

Definition of Done

• New ignite component DistributionZoneManager is introduced.
• It is inlined into ignite node start/stop flow.
• It's possible to create/alter/drop distribution zone with the help of ignite internal api that technically leads to cluster configuration changes.

Implementation Notes

1. First of all we should introduce new root zones configuration schema:

@ConfigurationRoot(rootName = "zone", type = ConfigurationType.DISTRIBUTED)
public class DistributionZonesConfigurationSchema {
/** Global integer id counter. Used as an auto-increment counter to generate integer identifiers for distribution zone. */
@Value(hasDefault = true)
public int globalIdCounter = 0;
 
/** List of configured distribution zones. */
@NamedConfigValue
public DistributionZoneConfigurationSchema distributionZones;
}

and zone configuration itself:

/**
 * Distribution zone configuration schema class.
 */
@Config
public class DistributionZoneConfigurationSchema {
    /** Zone name. */
    @InjectedName
    public String name;

    /** Integer zone id. */
    @Immutable
    @Range(min = 1)
    @Value(hasDefault = true)
    public int zoneId = 1;

    public int dataNodesAutoAdjustScaleUp;

    public int dataNodesAutoAdjustScaleDown;

    public int dataNodesAutoAdjust;
} 

Filter and affinity function type will be added to configuration later.

2. It's also required to introduce DistributionZoneManager as an IgniteComponent that should be started and stopped during node start and stop flow. The proper place to insert distributionZoneManager.start() is somewhere after clusterCfgMgr.start().

3. DistributionZoneManager should expose (as in internal API) methods to create alter and drop distribution zones.

4. Aforementioned create/alter/dropZone API should be available as part of Ignite @TestOnly internal api.

5. Internally all that methods should call update configuration closures. 

6. The only interesting part here is input data and drop validations. 

• In case of drop we should check whether there are tables binded to given zone. Let's say that CASCADE is not supported for now.
• Zone name should be checked for uniqueness. Let's ask SE teem about proper way of doing such checks, maybe there's an annotation that will help.
• Neither scaleUp or scaleDown are compatible with common auto adjust, so we should complete create result future (yep it's async) exceptionally if user specifies both (scaleUp || scaleDown) and common auto adjust. In case of alter proposed property should override non-compatible ones. 
• All-in-all some explicit validation, some configuration validators (see @TableValidator) and  tests are expected.

 7. Lot's of unit tests are expected to be written, that will check that distibutionZoneManager.create()/update()/drop() is either returns future completed exceptionally with proper exception or actually change the configuration.

8. Please pay attention, that within given ticket its' not expected for partitions and replicas to be moved inside Zones. Let it still be tables for now.