+++ This bug was initially created as a clone of Bug #1812584 +++

Description of problem:
It was observed that few manual upgrade runs failed and ended up having 4 etcd members. Upon closer look, the etcd operator looks for etcd member using the pod's node name to check if the member exists. In 4.3 and previous version, the discovery init container used to set hostname as etcd member name. 

During an upgrade, the operator sees an unready pod, does not find the member with hostname, adds the pod as a member. The etcd membership is extended to 4 member with 2 members point to the same pod as follows

-----
sh-4.2# etcdctl member list
6eaa8b03968621d, started, etcd-member-ip-10-0-139-57.us-west-2.compute.internal, https://etcd-0.scooter.group-b.devcluster.openshift.com:2380, https://10.0.139.57:2379
607b6768da8a2af5, started, ip-10-0-139-57.us-west-2.compute.internal, https://10.0.139.57:2380, https://10.0.139.57:2379
7ac864e4e29706a1, started, ip-10-0-170-79.us-west-2.compute.internal, https://etcd-2.scooter.group-b.devcluster.openshift.com:2380, https://10.0.170.79:2379
ef15d118336ebace, started, ip-10-0-155-153.us-west-2.compute.internal, https://etcd-1.scooter.group-b.devcluster.openshift.com:2380, https://10.0.155.153:2379


Version-Release number of selected component (if applicable):


How reproducible:
1/4 manual runs in my experience. Sometimes leads to total loss of control plane on upgrade

Steps to Reproduce:
1.upgrade to a recent 4.4 cluster from 4.3