feat: enable etcd health-check

[Yiyiyimu]

What this PR does / why we need it:

fix #3673
fix #3937.

Import health check of lua-resty-etcd, so

1. when one etcd node disconnected, apisix would try to connect another one and perform as normal, while health-check would continue print warning log about disconnected etcd node
2. when all etcd nodes disconnected, apisix would try to re-connect with etcd, with a cyclic backoff interval for 2s, 2s, 4s, ..., 1024s, 2s, 4s ... so the error log would not been flushed when etcd are all down.

TODO:

• for etcd node deployed in kubernetes, since nodes are behind the same domain, we could not know if one of them is taint, as talked in [discuss]: enable etcd health check #3692
• add test, but since the current health check does not work for kubernetes, need to implement a new CI pipeline for multiple etcd nodes

Pre-submission checklist:

• Did you explain what problem does this PR solve? Or what new features have been added?
• Have you added corresponding test cases?
• Have you modified the corresponding document?
• Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

[juzhiyuan]

We need another fix hh

[Yiyiyimu]

Things get a bit weird right now 😕

Before I work on this fix, I test that if killing one node out of an etcd cluster, apisix would fail, as those related issues talk about. However, right now when I test this scenario again on the master branch, apisix would not be affected by the closed etcd node and runs normally. I checked the recent commits and it seems no changes have applied to this problem.

Could someone help me to reproduce the program again

---

Test running apisix and etcd in Kubernetes, delete one etcd node, and apisix runs normally with master branch. So don't know if anything went wrong yet.

[Yiyiyimu]

Waiting for lua-resty-etcd new release: api7/lua-resty-etcd#129

[Yiyiyimu]

Waiting for api7/lua-resty-etcd#131

---

Done

[tokers]

Will step 10 too large? As 1024 seconds is too long.

[Yiyiyimu]

I'm not so familiar with the production environment. Do you have some recommendations, like 8, around 4 mins at most? @tokers

[tokers]

Maybe 6 is enough, also, since we are in a timer, keep a Nginx timer living for a long while is not a good practice as it might cause the memory leaky.

[Yiyiyimu]

Thanks for suggestion!
Changed to use outside counter till 32 to avoid keeping nginx timer too long. PTAL @tokers