Installation tests v3

[grusev]

Reference Issues/PRs

What does this implement or fix?

Those are installation tests targeted to be executed against different versions of arcticdb from conda and pypi without building our project.

GitHubWorkflow (not yet finished)

allows matrix execution of selected combinations of OS-es and Pytho versions. For each it install artcicdb from conda(mac-os) and pypi(other os-es), along with our test dependencies. We build also protobufs and execute our tests Not finished: ability to select arcticdb version, ability to run on demand with selected options from user

Link to successfull run with LMDB tests only: latest 5.3.3: https://github.com/man-group/ArcticDB/actions/runs/14494364845 5.1.2: https://github.com/man-group/ArcticDB/actions/runs/14509109094/job/40703855715 4.4.7: https://github.com/man-group/ArcticDB/actions/runs/14509267618

Added:

• @pytest.mark.installation - for marking only tests we want to execute
• ARCTICDB_STORAGE_LMDB - env var to allow LMDB to be selected only (if all local storages are disbaled ARCTICDB_LOCAL_STORAGE_TESTS_ENABLED=0 )

Modified:

• fixture 'lmdb_storage' is enhanced so that it can spawn other types of storages on demand, needed for resl storage installation tests where no arctic_* fixtures are available
• FixtureMarks class - currently holding only one decorator to helo easily expand installation tests that use lmdb-* fixtures to run also against real storages

Opened Questions:

1. The tests that we have in this PR can be executed on the master branch too. A workflow should be added for that purpose. However, if added such workflow perhaps only LMDB tests should execute, and the reason is that AWS S3 and GCP are costing quite much in that frequent execution along with a problem that they might fail due to reaching quota. Thus on master real storage tests can and should be added for execution at merge time in a separate workflow so that we keep track of failing tests and reasons.
2. What to do when old versions have changes in API that prevent current tests to run? (From here on we can safely assume that we can checkout also the same version of sources - at least from the point this PR is merged)
3. The tests we run against arcticdb requires whole current test framework, fixtures and its dependencies - this is too muc and could be reduced to bare minimum, See this PR: https://github.com/man-group/ArcticDB/pull/2316

Any other comments?

Checklist

Checklist for code changes...

• [ ] Have you updated the relevant docstrings, documentation and copyright notice?
• [ ] Is this contribution tested against all ArcticDB's features?
• [ ] Do all exceptions introduced raise appropriate error messages?
• [ ] Are API changes highlighted in the PR description?
• [ ] Is the PR labelled as enhancement or bug so it appears in autogenerated release notes?