…l has data left in its read buffer (#34185)

If we get a readable event on an fd and both the following happens:

- c-ares does *not* read all bytes off the fd

- c-ares removes the fd from the set ARES_GETSOCK_READABLE

... then we have a busy loop here, where we'd keep asking c-ares to
process an fd that it no longer cares about.

This is indirectly related to a change in this code one month ago:
#33942 - before that change, c-ares
would close the socket when it called
[handle_error](https://github.com/c-ares/c-ares/blob/7f3262312f246556d8c1bdd8ccc1844847f42787/src/lib/ares_process.c#L707)
and so `IsFdStillReadableLocked` would start returning `false`, causing
us to get away with [this
loop](https://github.com/grpc/grpc/blob/f6a994229e72bc771963706de7a0cd8aa9150bb6/src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc#L371).
Now, because `IsFdStillReadableLocked` will keep returning true (because
of our overridden `close` API), we'll loop forever.

Now that we have #33942 (and another
follow-up [fix](#34185)), I think the
issue from #25289 is likely fixed