New stability test case for ConfigMap rollout

[aylei]

We need a stability test case for ConfigMap rollout, so that we can verify:

• ConfigMap rollout won't break even in chaos environments;
• Problematic ConfigMap won't take down the cluster (only one of the replica will down if the rolling-update logic is right)
• After fixing a problematic ConfigMap, the cluster can recover without extra human intervention;
• ConfigMap rollout won't introduce other problems when interacting with other cluster operations.

General design of this case:

• Action: Update the config of pd/tikv/tidb to a new valid value
  • Desired: rolling-update, new config applied, no down time
• Update the start-script of pd/tikv/tidb to a new valid value
  • Desired: rolling-update, new config applied, no down time
• Update the config or start-script of pd/tikv/tidb to an invalid value
  • Desired: rolling-update blocked on the pod with the largest ordinal, no down time
• Rollback the config or start-script in the previous step
  • Desired: cluster recovers, no down time

[aylei]

@xiaojingchen @weekface @zyguan PTAL

[weekface]

LGTM

[xiaojingchen]

nice