[Feature] Introduce HTTP endpoint to restart embedded etcd

[unmarshall]

Feature (What you would like to be added):
Introduce a HTTP endpoint to allow external agents to restart the embedded etcd.

Motivation (Why is this needed?):
Use case:
To update advertise-peer-urls it is mandated by etcd to restart the member post making the member update call.
Refer: https://etcd.io/docs/v3.3/op-guide/runtime-configuration/#update-advertise-peer-urls

Today etcd-druid works around this missing feature by doing the following (Refer code):

1. etcd-druid updates the StatefulSet to ensure that any pending secret volume(s) are mounted and the config map changes are seen by the etcd-backup-restore container.
2. etcd-backup-restore makes the member update call as part of the starting the server. Refer code.
3. To ensure that the update to peer URL is reflected in the embedded etcd etcd-druid also triggers a deletion of all existing etcd pods forcing a restart.

The current implementation in etcd-druid is synchronous with waits embedded between steps. It is not crash friendly. If etcd-druid crashed in the middle of handling the peer URL TLS changes then it could result in a non-functioning etcd cluster. In addition etcd-backup-restore currently reports the status of peer URL TLS enablement by only looking at the mounted etcd configuration. This does not accurately indicate what the embedded etcd sees.

Therefore we need to follow the recommendations and ensure that the update is completed by first making the member update call immediately followed by restart of the member. The endpoint that is proposed to be exposed out of etcd-wrapper will be invoked by the etcd-backup-restore container just after the member-update call.

Approach/Hint to the implement solution (optional):

[shreyas-s-rao]

/close since it is no longer required for scale-up of etcds in gardener/etcd-druid#777