Add jaq

[jayvdb]

https://github.com/01mf02/jaq , jq clone

[NobodyXu]

Do we really need a jq clone support in this action?

I get that it is an alternative in Rust and I support it, but given that GHA already have jq and it is enough for most use cases, I'm not sure if this is needed since this action fallbacks to cargo-binstall for rust crates.

Sure it is a bit slower than supporting it here directly but most of the time it is fine and good enough, I don't think we should support everything here.

[NobodyXu]

I read through jaq description, it seems that they aim to be more correct (regarding floating point, etc), plus it's written in rust and use serde_json to parse json which provides better memory safety than C parser.

It makes sense for medical software and other area which pay great attention to safety and correctness.

[jayvdb]

In addition to the general "install-action vs cargo-binstall" aspect addressed with at #514 (comment) , the reason we want to use jaq and xh instead of jq and curl in our workflows is that our build process explicitly use jaq and xh, which are not identical to jq and curl, so that our product builds and V&V processes have as few non-Rust dependencies as possible. Especially with jaq, we've had to adjust the queries so they are supported by jaq.

Each and every non-Rust binary on our build workers needs extra paperwork, including "system" provided tools. And while https://github.com/rustsec/advisory-db tends to be very conservative, that is a good thing in my industry, there isnt an equivalent for C/C++ , so C/C++ binaries are not just extra paperwork - they require active monitoring of system library dependencies, instead of relying on the rustsec community.

[NobodyXu]

Thanks for explanation, that makes sense.

It seems that the CI has hit rate limit of GitHub, so it's quite slow.

[NobodyXu]

I have rebased the PR against main to fix the CI due to outdated cargo-binstall