Detach the jet codec

[ivanlele]

This PR updates the Rust codegen to match the interface changes introduced in BlockstreamResearch/rust-simplicity#358

[apoelstra]

I don't like this, but maybe it's necessary due to Rust language limitations. Let me dig through the rust-simplicity PR..

[apoelstra]

Oh, I see, it's because Jet::encode cannot have any generics if the trait is to be object-safe. Ugh.

This change is going to be pretty rough for performance. The BitWriter abstraction previously was (probably) just inlined when we were writing to slices/vectors, and now we are forced to do a function call through a vtable.. let me think for a short bit about better solutions before I just ACK this.

[apoelstra]

Okay. concept ACK 2acdd45. Will run through my test box. (I didn't verify the code in rust-simplicity but this one is straightforward enough that I think a visual code review is sufficient.)

I think we should revisit this later and introduce some sort of BitArray type that this function can return, and which BitWriter can consume, but that's a big change and I don't want to hold up the object-safety project over it. So this is good for now.

[apoelstra]

Actually, I changed my mind -- encode is good, but for decode, can we move the pub(crate) method back into the trait and just add a where Self: Sized bound to it?

Users who have a dyn Jet will be unable to call it. But users, and our own JetEnvironment impls, will be able to call the concrete methods, e.g. jet::Bitcoin::decode. With the pub(crate) solution, downstream users have no way to decode jets from a bitstream unless they have a transaction environment available. (And I don't want to just expose a freestanding pub method because I think it's an ugly API.)

[ivanlele]

Actually, I changed my mind -- encode is good, but for decode, can we move the pub(crate) method back into the trait and just add a where Self: Sized bound to it?

@apoelstra, Done. I also applied a similar change to the new parse method.

As a result, the PR in BlockstreamResearch/rust-simplicity now contains only about 80 changes (excluding the revert of the commit that rolled back auto-generated files):
https://github.com/ivanlele/rust-simplicity/compare/4bef6bb10e85c972f387856c20d0f4fa9fe4c0b9..4d89a8f372d232bfb85f1056ce3a48712c8ba31d

[apoelstra]

utACK. Need to chase down error: Package ‘python3.13-uv-0.8.23’ in /nix/store/726rmj7j1cfrrif394yqg3qwp5z3hy4k-nixos/nixos/pkgs/by-name/uv/uv/package.nix:71 is marked as broken, refusing to evaluate. when I try to test it. Maybe I need to update my nixpkgs, or maybe updating it is exactly the wrong thing to do..

Edit

    # Builds on 32-bit platforms fails with "out of memory" since at least 0.8.6.
    # We don't place this in `badPlatforms` because cross-compilation on 64-bit
    # machine may work, e.g. `pkgsCross.gnu32.uv`.
    broken = stdenv.buildPlatform.is32bit;

Weird that this triggers on my 64-bit box..

Edit Oh, oops, I wasn't pinning my nixpkgs at all since my last reboot. We will have to deal with this issue eventually, but not now..