Unify end-to-end tests

[xzfc]

Is your feature request related to a problem? Please describe. As a new contributor, I find the process of running all of the end-to-end tests to be complicated. There are a bunch of script files, and the way they are run is inconsistent:

• tests/snapshots/snapshots-recovery.sh: builds qdrant docker image and tests it.
• tests/storage-compat/storage-compatibility.sh: builds ./target/debug/qdrant using cargo and runs it.
• tests/basic_*_test.sh: calls curl | jq / gpcurl to already running qdrant instance. They don't check the result, just print responses to stdout.
• ~tests/openapi_integration_test.sh: runs all pytest files from openapi/tests/openapi_integration using dockerized pytest. Has requirements.txt and Dockerfile to build pytest docker image.~ #3606
• tests/consensus_tests: pytest tests. Builds qrant docker image and runs it via docker-compose.
• tests/shard-snapshot-api.sh: is not a test but rather a helper tool to call an API.
• tests/grpc_consistency_check.sh: check that autogenerated files are up to date.

Also, it's not clear where I am supposed to add new tests and which language to use (bash or python).

Describe the solution you'd like It would be helpful if there were a single command to run all of the end-to-end tests or to run specific tests (akin to cargo test -- --test TEST_NAME or pytest TEST_FILE.py::TEST_NAME). It should be possible to run tests without building a qdrant docker image since the building process is quite slow.

As for grpc_consistency_check.sh, I feel that its invocation should be included in a generic task runner script (e.g. make gen, alongside make e2e-tests, make fmt, and make lint). This would make pre-push checks easier.

Describe alternatives you've considered Add a list of test files with an instruction on how to run them to the documentation. However, the documentation tends to become outdated over time as it's easy to forget to update it when changing the test or adding a new one.

[DXist]

I think we shouldn't mix integration tests with end-to-end system tests. End-to-end tests require external tools and run against real system APIs. Integration tests could include subset of the system into test binary potentially using stub components to test other modules in isolation and in controlled environment.

Both types of tests are different and can implement different ways to run them.

It should be possible to run tests without building a qdrant docker image since the building process is quite slow.

The current Dockerfile doesn't use build cache. Build cache could significantly speedup build process. Besides default PROFILE is release and should be changed to dev. Build cache and incremental compilation will be more practical for interactive use.

[xzfc]

I meant end-to-end tests, thanks for the correction.