[C++] Fix the race condition of connect timeout task

[BewareMyPower]

Fixes #14665

Motivation

In C++ client, a connect timeout task is created each time before an
asynchronous connect operation is performed, if the connection cannot be
established in the configured timeout, the callback of the task will be
called to close the connection and then the createProducer or
subscribe methods will return ResultConnectError.

ClientConnection::connectTimeoutTask_, which is a shared pointer,
represents the timeout task. However, after ClientConnection::close is
called, the shared pointer will be reset, and the underlying PeriodicTask
object will be released. After that, when stop method is called on the
released PeriodicTask object in the callback (handleTcpConnected), a
segmentation fault will happen.

The root cause is that connectTimeoutTask_ can be accessed in two
threads while one of them could release the memory. See #14665 for more
explanations. This race condition leads to flaky Python tests as well,
because we also have the similar test in Python tests. See

pulsar/pulsar-client-cpp/python/pulsar_test.py

Lines 1207 to 1221 in f7cbc1e

	def test_connect_timeout(self):
	client = pulsar.Client(
	service_url="pulsar://192.0.2.1:1234",
	connection_timeout_ms=1000, # 1 second
	)
	t1 = time.time()
	try:
	producer = client.create_producer("test_connect_timeout")
	self.fail("create_producer should not succeed")
	except pulsar.ConnectError as expected:
	print("expected error: {} when create producer".format(expected))
	t2 = time.time()
	self.assertGreater(t2 - t1, 1.0)
	self.assertLess(t2 - t1, 1.5) # 1.5 seconds is long enough
	client.close()

So this PR might also fix #14714.

Modifications

Remove connectTimeoutTask_.reset() in ClientConnection::close. After
that, the connectTimeoutTask_ will always points to the same
PeriodicTask object, whose methods are thread safe.

Verifying this change

Execute the following command

./tests/main --gtest_filter='ClientTest.testConnectTimeout' --gtest_repeat=10

to runs the testConnectTimeout for 10 times. In my local env, it never
failed, while before applying this patch, it's very easy to fail.

[lhotari]

Great work @BewareMyPower ! Thanks for finding out the reason behind so many flaky C++ and Python tests.

[BewareMyPower]

This bug was introduced from #14587, which was not cherry-picked into branch-2.8 and branch-2.9. I'll cherry-pick it first.

I found the flaky test on branch-2.9 is testReferenceCount (#14719), I'll work on this issue soon.

FAILED TESTS (2/274):
      37 ms: ./main ClientTest.testReferenceCount (try #1)
      31 ms: ./main ClientTest.testReferenceCount (try #2)

[BewareMyPower]

I just found this PR brings a regression of #14587 and I've opened another PR (#14834) to fix it.