add quint interleaving spec

[ecioppettini]

A "split" of #185

It's not exactly a split since it's more like I re-typed the spec line by line and in the process I adjusted some things. But it's close enough where rebasing that one on top of this shouldn't be a huge issue.

This doesn't include any of the changes that require changing the nightstream version, so it doesn't include the runtime part. Including the host-call tracing and the encoding-decoding part.

Hopefully this should make it easier to review. As I probably mentioned before, a good reference for the role of this is the existing relation of the existing starstream-interleaving-spec(-legacy) and starstream-interleaving-proof(-legacy). This new package is a replacement for the former.

I still decided to just remove the two runtime crates, I don't think what they add right now is that useful. Still keeping the circuit and the ledger/spec as references though.

Questions

• cargo test -p starstream-interleaving-spec requires quint to be installed (it's called from rust)

it can be installed by npm ci in that directory, which is fine for the ci/development, but since it's not cargo it means just running cargo test will fail

should I feature-gate these tests? should I expect people to just ignore the test? should I add #[ignore] to them?

[SpaceManiac]

requires quint to be installed

Since Quint is written in JS, we have two options:

• Depend on Quint's binary releases which bundle the Deno interpreter
• Depend on Quint via NPM

In either case, I think the sensible thing is to install it in build.rs. Maybe this for now?

use std::process::Command;

fn main() {
    assert!(Command::new("npm").arg("i").status().unwrap().success());
}

[ecioppettini]

requires quint to be installed

Since Quint is written in JS, we have two options:

* Depend on Quint's binary releases which bundle the Deno interpreter

* Depend on Quint via NPM

In either case, I think the sensible thing is to install it in build.rs. Maybe this for now?

use std::process::Command;

fn main() {
    assert!(Command::new("npm").arg("i").status().unwrap().success());
}

Using build.rs works I guess, not sure how idiomatic it is though. Network access in build scripts is not the cleanest thing (it doesn't always work, like with nix). That's why my first instinct was to put these tests behind a feature so that if someone doesn't have it installed it just doesn't fail (I'm not sure we necessarily need everyone to run these tests by default, and the CI will detect it anyway).

I guess I could make the tests themselves run the command if not installed though. In reality that crate will only be used for tests for the most part, but it will probably also contain some shared types between the runtime and the circuit.

[SpaceManiac]

not sure how idiomatic it is though

It's not perfect, as you say. I suppose the tests being feature-gated and run on CI is also "good enough". I don't see a clean solution so I don't feel strongly about this.

[ecioppettini]

not sure how idiomatic it is though

It's not perfect, as you say. I suppose the tests being feature-gated and run on CI is also "good enough". I don't see a clean solution so I don't feel strongly about this.

I decide to #[ignore] them for now, and npm test in that directory runs with --included-ignored

The CI runs them anyway, so we'll know if they break.

In the future, if these (and the circuit tests I'll add later) become more important we can unignore them. Or put them behind a feature. Or maybe I can drive these tests from a rust binary, an auxiliary script or smh.

But tbh I feel like requiring manually running npm ci once in the crate directory should be fine. The alternatives feel too hacky to me.