Based on discussion from #7597

Check whether serialized Get/Txn responses are ordered by caching last known revision on the client side. Each Get/Txn client call will check the response's header revision is equal to or greater than the last known revision at the time of issuing the RPC.

This avoids the case where an etcd client connects to multiple endpoints, issues multiple rev=0 Gets, and receives revisions older than those already received. If this happens on a single proxy/server, it's a bug.

Two behavior notes:

1. retry on same server within some duration (endpoint might just be slow to get update)
2. if retries fail after some time, switch endpoint