feat(split): secondary start split

[hycdong]

Simple partition split process

1. meta receives client partition split request, and change partition count split: meta start partition split #286
2. replica notices partition count changed during on_config_sync feat(split): add splitting_replicas while on_config_sync #653
3. parent partition create child partition split: parent replica create child replica #291
4. parent prepare states for child to learn feat(split): parent replica prepare states #299
5. child partition async learn states from parent feat(split): child replica learn parent prepare list and checkpoint #309 feat(split): child replica apply private logs, in-memory mutations and catch up parent #319
6. child notify parent catch up feat(split): child notify parent catch up #390
7. update child group partition count feat(split): add update_child_group_partition_count #645
8. register child partition feat(split): register child partition #391
9. update parent group partition count feat(split): parent group update partition count #654

More partition split discussion in issue #69 and partition split design doc
This pr solves the part of third step of partition split, which is bold in process description.

What this pr solve

Primary parent notices that it should start partition split by on_config_sync, then it will pass it to secondary through group_check by calling broadcast_group_check, and put split related filed in group_check_request, when secondary receives this request, it will call trigger_secondary_parent_split.

[neverchanje]

How primary knows its child_gpid? I think it certainly can calculates out on its own gpid.
Such as parent_gpid(1, 4) => child_gpid(1, 4+PARTITION_COUNT)
If primary can, the secondary can too. Primary does not have to sync this knowledge to secondaries.

[hycdong]

Primary calculate child_gpid in trigger_primary_parent_split, if it found the partition_count sync from meta server is double of its own value:

rdsn/src/replica/split/replica_split_manager.cpp

Lines 1136 to 1140 in d850ee7

	auto child_gpid =
	gpid(get_gpid().get_app_id(),
	get_gpid().get_partition_index() + _replica->_app_info.partition_count);
	add_child_request.__set_child_gpid(child_gpid);
	parent_start_split(add_child_request);

It is a safe solution to sync it to secondary, if any bug happened, such as duplicated split, secondary may get wrong child_gpid, leading dangerous result.

[neverchanje]

enum split_status
{
    // idle state
    NOT_SPLIT,
    // A replica is splitting into two replicas, one call parent, one call child.
    SPLITTING,
    PAUSING,
    PAUSED,
    // After the split successfully cancelled, the state turns into NOT_SPLIT.
    CANCELING
}

I'd recommend add some comments on the split_status of replication.thrift.