Connection pool size configuration

[muzarski]

Fixes: #240
Ref: #132

Depends on: #280 (I need metrics support to implement one integration test).

Implements:

• cass_cluster_set_core_connections_per_host
• cass_cluster_set_core_connections_per_shard (as an extension to cpp-driver API)

Integration tests

Existing ErrorsConnectionTimeouts metrics test

CASSANDRA_INTEGRATION_TEST_F(MetricsTests, ErrorsConnectionTimeouts) {
  CHECK_FAILURE;

  Session session =
      default_cluster().with_core_connections_per_host(2).with_connect_timeout(1).connect(
          "", false); // Quick connection timeout and no assertion

  CassMetrics metrics = session.metrics();
  EXPECT_GE(2u, metrics.errors.connection_timeouts);
}

I don't know who implemented this test, but (IMO) it's just wrong. So my understanding of intentions is:

1. we set 2 connections per host
2. we set low connect timeout
3. we expect at least 2 connection timeouts registered in the metrics

If those were the intentions, the EXPECT_GE(2u, metrics.errors.connection_timeouts); is wrong - it should be the other way around. Currently it expects 2 >= connection_timeouts.

Ok, so let's say we fix it. It still won't work with rust driver. The Session object will not even be built - we will fail to open a control connection (because of timeouts) and fail to fetch the metadata. In particular, we won't even be able to call Session::get_metrics() - the cass_session_get_metrics will return early with some log error message.

Thus, I'm not enabling this test.

Fun fact: in my local setup, this test passes. Even though, the connect timeout is low, it is not triggered. And then, the metrics.errors.connection_timeouts is 0 - this means that aforementioned assertion passes as well.

My new StatsShardConnections metrics test

I implemented simple test where we configure a pool size to be 2 connections per shard (cass_cluster_set_core_connections_per_shard). It checks whether all connections are registered in the metrics. The expected value is at least nr_hosts * nr_shards * 2.

Pre-review checklist

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• PR description sums up the changes and reasons why they should be introduced.
• [ ] I have implemented Rust unit tests for the features/changes introduced.
• I have enabled appropriate tests in .github/workflows/build.yml in gtest_filter.
• I have enabled appropriate tests in .github/workflows/cassandra.yml in gtest_filter.