fix(provider-tck): say that the HTTP control drives its backend over HTTP

`HttpControl` did not declare the optional `control_api` property, so a flagd
conformance report omitted `backend.controlApi` -- putting a run driven over the
normative control API on the same footing as one from a control that declined to
say which path it took. That distinction is the whole point of the field: an
in-process claim from a provider that does have a backend is meant to be
readable as such.

The property is documented on `BackendControl` in the base, so declaring it here
adds nothing to the adopter API. Every operation on this class is an HTTP request
to `control-api.yaml`, which makes "http" the one answer it can give without
qualification.

Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>

Author: aepfli

tools/openfeature-provider-tck/README.md

@@ -375,10 +375,10 @@ This mirrors what `openfeature-flagd-api-testkit` already does for the flagd tes
 | `test_lifecycle_steps` | the steps that call the provider directly | the in-memory suites skip `@lifecycle`, so the shutdown, re-initialise and metadata steps are driven against a recording provider instead |
 | `test_declaration` | what a `TckConfig` claims | none of it is observable in a pass or a fail, so nothing else would catch it |
 | `test_extensions` | an adopter's own scenarios | an extension runs inside the canonical suite, changes nothing for an adopter who has none, and cannot take a canonical scenario's identity |
-| `test_http_control` | `HttpControl` | the `/reset` fallback and the disconnect bookkeeping, against a stubbed control API |
+| `test_http_control` | `HttpControl` | the `/reset` fallback, the disconnect bookkeeping and the control-API it reports, against a stubbed control API |
 
 ```
-123 passed, 21 skipped, 2 xfailed
+124 passed, 21 skipped, 2 xfailed
 ```
 
 No Docker and no network beyond loopback. The conformance suites take under a second;

tools/openfeature-provider-tck/src/openfeature/contrib/tools/provider_tck/httpcontrol.py

@@ -118,6 +118,18 @@ def __init__(
         # prepare_scenario starts it rather than merely resetting flag state.
         self._backend_maybe_down = False
 
+    @property
+    def control_api(self) -> str:
+        """Report that this control drives its backend over the HTTP control API.
+
+        The optional property ``BackendControl`` documents. This is the one
+        control in the package that can answer it without qualification: every
+        operation below is an HTTP request to ``control-api.yaml``. Leaving it
+        unsaid would put a report from the normative control path on the same
+        footing as one from a control that declined to say which path it took.
+        """
+        return "http"
+
     @property
     def description(self) -> str:
         return f"the backend at {self._base_url}, driven over the control API"

tools/openfeature-provider-tck/tests/test_http_control.py

@@ -221,3 +221,14 @@ def test_a_trailing_slash_does_not_produce_a_double_slash_path() -> None:
         HttpControl(stub.base_url + "/").change_flag()
 
         assert stub.paths == ["/change"]
+
+
+def test_the_control_reports_which_api_it_drives_the_backend_through() -> None:
+    """The optional property ``BackendControl`` documents, answered here.
+
+    A control that stays quiet has the field omitted from its report, which puts
+    the normative HTTP path on the same footing as one that declined to say. This
+    control can say, so it does.
+    """
+    with _StubControlApi() as stub:
+        assert HttpControl(stub.base_url).control_api == "http"