Idea: Hurl for custom uploaders

[nikeee]

Custom uploader specs might not work for all scenarios.

Maybe we could leverage Hurl to define how to upload something. The path to the image as well as some metadata could be supplied to the script by injecting variables:
https://hurl.dev/docs/templates.html#injecting-variables

This would make it possible to model complex scenarios for APIs that require multiple HTTP requests to do stuff.

Error handling would be pain, I guess. Also, shipping Hurl with HS would be needed (or some heavy lifting like with FFmpeg, which is also error prone).

[nikeee]

Hurl files could be prepended with a YAML metadata block that basically resembles the current UploaderMeta.

[nikeee]

We'd have some trouble displaying a progress bar.

Also, Hurl is primarily focused on testing HTTP APIs. Maybe there is an alternative that can be used to achieve the same goal.

We should avoid forking Hurl, but without support for FFI, we're going to have a hard time.
If we fork it, we can also add support for progress bars by implementing a callback function that fills a buffer, so we can keep track of what has been sent. That would also avoid saving the image to disk.

[nikeee]

We could also evaluate how much work it would be to re-implement the important (for us) parts of Hurl. For example, we don't need assertions.

Would be nice to be a proper subset of Hurl, so people could test their stuff with it.

When usiung Hurl as a library, we'd need to do FFI (p/invokes) with that. We must evaluate how much overhead this comes with, when passing stuff around.

[nikeee]

We depend on Orange-OpenSource/hurl#284 and Orange-OpenSource/hurl#306 for this.

Maybe we could implement a small, compatible subset of hurl files for this. This would be a lot of work.