Integration of OGC API benchmarks

[JanssenBrm]

This PR integrates OGC API benchmark support into the QA benchmarking framework and refactors the benchmark/scenario implementation into a cleaner, extensible architecture.

The previous implementation was openEO-focused and quite monolithic. This branch introduces a backend-agnostic runner model so benchmark execution can support multiple protocol families (openEO and OGC API Processes) with shared reporting and comparison logic.

Main changes:

• Benchmark architecture refactor
  • Split monolithic benchmark logic into a package structure with dedicated modules for common helpers, openEO integration and OGC API integration
  • runner abstractions and runner factory
  • Introduced a typed runner artefact contract to normalise metadata and results across backends.
  • Added a new OGC benchmark scenario for GEP API OST for testing
• Scenario architecture refactor
  • Split scenario handling into dedicated modules for common scenario utilities, scenario base model, openEO, scenario model and OGC API scenario model and a scenario factory
  • Unified scenario loading through factory-based dispatch.
• New OGC API benchmark support
  • Added OGC API authentication support (token and client-credential/device flow paths).
  • Added OGC API job lifecycle support benchmark execution
  • Added OGC API result extraction and download flow, including schema-aware parsing for structured outputs.

[algorithm-services-catalogue]

🔍 Catalogue's Preview Site Deployed

Your changes have been deployed to the preview site:

🔗 Preview URL: https://esa-apex.github.io/apex-algorithms-catalogue-web/pr-preview/pr-518/

This preview will be updated automatically when you push new changes to your PR.

[soxofaan]

this is quite a large diff/refactor and I'm a bit short on time to review this in depth, let alone try some things out.
I have no immediate objections from a superficial glance, so I'm fine with going forward with this.

One design note maybe:
the proposal pushes all types of benchmarks through a single test function test_run_benchmark and to do that quite some abstraction is introduced.
This assumes that all benchmark flows fit the same structure and aspects in a way that can be abstracted commonly which is not sure. Mismatches in the abstraction layer could lead over time to messy and hard to maintain workarounds.
I wonder if it isn't easier to replace a single test_run_benchmark with dedicated test functions, e.g. test_run_benchmark_openeo, test_run_benchmark_ogc, ..., which reduces the need for abstraction, but still allows for code reuse where applicable.

[JanssenBrm]

Thanks for your suggestions @soxofaan.

On the design note, I think they both have their pros and cons. For now, OGC API and openEO are following a similar pattern when it comes to benchmarks, and the abstraction actually makes it easier to ensure they are treated in the same way. Common features, such as tracking of the stages, storing the metrics, ... are kept consistent this way.

So if there are no immediate objections, I suggest keeping the abstraction level for now and splitting it up if necessary in future integrations.

[HansVRP]

factory and runners are a bit vague names to me.

but that is mainly a personal opinion

[JanssenBrm]

I see, yes, the name factory refers to a software engineering design pattern (https://www.geeksforgeeks.org/system-design/factory-method-for-designing-pattern/), which might indeed be confusing, but feel free to suggest an alternative name.

I was struggling to find a good name for runners as well, an alternative would be something like OpenEOBenchmarkExecutor or similar?