Subgraph enumeration can overflow u32

[jdaymude]

When attempting to run a dataset benchmark on coconut_220, three molecules cause ORCA-naive (i.e., ORCA with --no-bounds) to panic : 0161.mol, 0166.mol, and 0185.mol. To reproduce the error:

> cargo build --release
> ./target/release/orca data/coconut_220/0161.mol --no-bounds
thread 'main' panicked at src/assembly.rs:315:66:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> ./target/release/orca data/coconut_220/0166.mol --no-bounds
thread 'main' panicked at src/assembly.rs:315:66:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> ./target/release/orca data/coconut_220/0185.mol --no-bounds
thread 'main' panicked at src/assembly.rs:315:66:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

(Unfortunately, these are all fairly slow to run, apologies if you're trying to reproduce.)

For the record, ORCA-naive successfully computes the assembly indices of all other molecules in coconut_220, and no errors occur for any molecules at all when using any of the bounds (log, integer chain, vector chain).

[AgentElement]

coconut_220/0161.mol runs for over 6 hours on my machine. A back-of-the-envelope calculation shows that the index enumeration could run fast enough to overflow a u32 (~4 billion states searched). I don't think I want to swap to u64s, so I'm tempted to make this a wontfix bug, and instead just drop ORCA-naive from the coconut benchmarks.

[jdaymude]

We probably need some kind of user-facing warning about this in general instead of just throwing wontfix on it and calling it a day. Especially if we're billing --no-bounds as the way we compute the baseline size of the search space, it's not hard to imagine somebody running naive against whatever molecule they're curious about and then getting this cryptic error. So I see this less as a specific coconut_220 issue and more an overall limitation of that algorithm (it's slow, and its search spaces are huge).

The only other thing I wonder about is if there are molecules that are sufficiently complex that their search spaces exceed u32 even with bounds (e.g., the log bound). Again one could make the argument that if such a thing exists, it's probably too slow to want to use the log bound, but this requires the user to know ahead of time the properties of their molecules to watch out for. Not the most satisfying situation to be in.

[jdaymude]

After discussion with @AgentElement @colemathis, we have decided:

• Change from u32 to u64 everywhere. This puts our best foot forward in terms of what folks might try to do, acknowledging that for every finite amount of storage, there exists a molecule that causes this problem.
• Not write a custom panic handler for this particular error, as it would require a check in a very hot part of the code, leading to performance degredation.
• Add a known issues section to README and link this issue.

[colemathis]

u32 changed to usize not u64 implemented on commit: 019d51e

[colemathis]

Benchmark molecules changed on main after this error was discovered.