Speed up 10x test_storage_rabbitmq::test_failed_connection

[pamarcos]

This is the first thing I should've done to make my life easier when testing it. Now that I have grasped better what the test does, I can do it in confidence:

Tune the numbers to get the same behavior but with much less work done. This is not an stress test, so it's still good if we use 100 messages instead of several thousands as long as we test the same thing.

Before

91.13s call     test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_1
87.11s call     test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_2
8.56s teardown test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_2
6.23s setup    test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_1
3.22s teardown test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_1
0.45s setup    test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_2

After

14.35s call     test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_1
13.54s call     test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_2
8.32s teardown test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_2
6.35s setup    test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_1
3.42s teardown test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_1
0.40s setup    test_storage_rabbitmq/test_failed_connection.py::test_rabbitmq_restore_failed_connection_without_losses_2

Also, the RabitMQMonitor seems not very consistent according to some false positive reports such as https://s3.amazonaws.com/clickhouse-test-reports/PRs/79212/460d6f15bdb3b12c485c171a7e13c9bb7955e4a6//integration_tests_asan_old_analyzer_1_6/integration_run_test_storage_rabbitmq_test_failed_connection_py_0.log

We're getting this, even though all messages were consumed ok in ClickHouse:

        if self.expected_published > 0 and self.expected_published != len(self.published):
>           pytest.fail(f"{len(self.published)}/{self.expected_published} (got/expected) messages published. Sample of not published: {_get_non_present(self.published, self.expected_published)}")
E           Failed: 195056/300000 (got/expected) messages published. Sample of not published: [195056, 195057, 195058, 195059, 195060, 195061, 195062, 195063, 195064, 195065]

Thus, let's make it a warning log instead of a hard failure for now

Related to #71049

Changelog category (leave one):

• CI Fix or Improvement (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

...

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

[clickhouse-gh]

Workflow [PR], commit [3df7dbb]