[jwrosewell]

Closes #157

Problem

ShareUsageElement::new built the blocking reqwest client it sends with on the thread that created the element (share_usage_element.rs L531-L545). In a debug build, building a blocking client inside an async runtime panics with "Cannot drop a runtime in a context where blocking is not allowed", because reqwest builds and drops a runtime of its own to check where it is, and tokio refuses to drop a runtime inside another's async context.

A web server built on axum usually creates its pipeline inside its runtime, in #[tokio::main] async fn main. Usage sharing is on by default in both facade builders, and the README's web example builds its pipeline inside an async fn (README.md L232-L237). The axum examples avoid the panic only by building the pipeline before the runtime starts, with a comment that says why (dd-web-getting-started-onprem.rs L120-L125).

Change

• The HTTP sender holds the URL and builds its client the first time it sends, which is always on the element's background thread. The client is dropped there too, when the thread ends.
• A client that cannot be built makes each send fail with the reason, which is counted and logged like any failed send. The old code fell back to Client::default(), which panics when building fails.
• The documentation of ShareUsageElement::new says the element can be created inside an async runtime.
• A test, share_usage_is_created_and_used_inside_an_async_runtime, in pipeline-engines-fiftyone/tests/elements.rs, creates the element, processes a request and drops the element inside a current-thread tokio runtime, and checks the local capture server received the record. tokio with its rt feature is a new dev-dependency of the crate for it.

How it was verified

On Windows 11 with Rust 1.95.0. The new tests were first run against the base commit 9fe201e, with nothing else changed, using cargo test -p fiftyone-pipeline-core -p fiftyone-pipeline-engines-fiftyone --no-fail-fast -- --test-threads=1, and each failed as shown.

• share_usage_is_created_and_used_inside_an_async_runtime panicked at tokio's runtime/blocking/shutdown.rs:51:21 with "Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context."

With the change, cargo fmt --all -- --check passes on a local merge of this branch with the six other branches raised alongside it. The test and lint counts on this branch and on that merge are added below as the runs finish.

Behaviour that changes

• ShareUsageElement::new and with_defaults no longer panic inside an async runtime in a debug build.
• The HTTP client, and the runtime thread reqwest starts for it, now exist only once the element has a message to send.

What remains

• The data update service (data_update_service.rs L116-L121), which the on-premise facade builders create while automatic updates or the file watcher are on, and the cloud request engine's built-in HTTP client (http.rs L136-L145) also build blocking reqwest clients as they are created. They are outside this change, so this change alone does not make every facade pipeline safe to build inside a runtime.
• The README's web example and the comment in the axum examples can be changed once all three are.