There is a potential concurrency problem in all admin PATCH APIs when
two patch requests come in simultaneously, in such case, the patched
result of the first applied request will be overridden, also the
probability is tidy, but from the perspective of software's robust,
that's not what we wanna to see.
In this commit, we use the optimistic locking to avoid this problem, for
the example aforementioned, the second PATCH request will failure, and
it's up to the user to retry this PATCH request again.
The optimistic locking mechanism in ETCD v3 APIs is showed by it's
transcation mechanism.
Signed-off-by: tokers <zchao1995@gmail.com>
