[release-3.4] consistent-index not persisted when committing the member deletion operation

[ahrtr]

Bug report criteria

• This bug report is not security related, security issues should be disclosed privately via etcd maintainers.
• This is not a support request or question, support requests or questions should be raised in the etcd discussion forums.
• You have read the etcd bug reporting guidelines.
• Existing open issues along with etcd frequently asked questions have been checked and this is not a duplicate.

What happened?

Only release-3.4 has this issue.

When deleting a member, etcd will forcibly commit the transaction, but the consistent-index isn't persisted in such case. If etcd gets restarted or upgraded( 3.4 -> 3.5) right after deleting a member, etcd will re-apply the confChanges, but it shouldn't.

Since membership data isn't managed by mvcc, so it isn't that very serious.

It causes the failure of 3.5's case TestDowngradeUpgradeClusterOf3, when a generic verification (to verify the membership in v3store is in sync with v2store) is added in #19563.

What did you expect to happen?

.

How can we reproduce it (as minimally and precisely as possible)?

.

Anything else we need to know?

No response

Etcd version (please run commands below)

$ etcd --version
# paste output here

$ etcdctl version
# paste output here

Etcd configuration (command line flags or environment variables)

paste your configuration here

Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)

$ etcdctl member list -w table
# paste output here

$ etcdctl --endpoints=<member list> endpoint status -w table
# paste output here

Relevant log output

[ahrtr]

When deleting a member, etcd will forcibly commit the transaction, but the consistent-index isn't persisted in such case. If etcd gets restarted or upgraded( 3.4 -> 3.5) right after deleting a member, etcd will re-apply the confChanges, but it shouldn't.

The issue was introduced in #17238