Extremely unlikely race conditions in internal::AsyncRetryLoop()

[coryan]

Consider the current implementation of the asynchronous retry loop, in particular how the pending_operation_ is set after the callback may have been invoked:

google-cloud-cpp/google/cloud/internal/async_retry_loop.h

Lines 111 to 115 in 0c09efc

	auto op =
	functor_(cq_, std::move(context), request_).then([self](future<T> f) {
	self->OnAttempt(f.get());
	});
	SetWaiting(std::move(op));

If the callback is immediately completed (or the scheduler puts a long sleep before line 115) the pending_operation_ may be set to a future that is no longer active, which means the cancel request has no effect:

google-cloud-cpp/google/cloud/internal/async_retry_loop.h

Lines 192 to 200 in 0c09efc

	void Cancel() {
	std::unique_lock<std::mutex> lk(mu_);
	cancelled_ = true;
	if (state_ != kWaiting) return;
	future<void> f = std::move(pending_operation_);
	state_ = kIdle;
	lk.unlock();
	f.cancel();
	}

This is extremely rare, it would require multiple operations completing very fast, and separate threads going to sleep. Nevertheless, we should fix this.