feat: popgen-htslib crate

[molpopgen]

No description provided.

[molpopgen]

@laggycomputer -- it has struck me that we don't need to return a Vec for the "record adapter". We could instead return an opaque type that implements Iterator<Item = Option>. I bet we could get the lifetimes worked out?

[laggycomputer]

I'll look at the iterator later today.

[molpopgen]

I can take a crack at it on Monday. Getting tests to work via tempfiles to make the htstlib readers happy fried my Friday brain.

[laggycomputer]

misisng_docs is now failing, but no rush.

[molpopgen]

yeah -- I want to totally replace the allocating implementation with one based on Iterator.

[molpopgen]

oh boy -- existing tests were also passing even though there was a bug in the crate code!

[molpopgen]

I hit a road block on the iterator business. There's a lot of borrowing and flattening that would have to happen. Internally, htslib is allocating into Vec at various points but not providing IntoIter impls. It made for a bit of a nightmare.

[molpopgen]

hmmm -- there is probably some way to get it to go by holding another internal index and using .skip(i).take(1) to get specific alleles. I'd have to study the htslib internals a bit more closely to see if that would be O(1) or not.

[molpopgen]

@laggycomputer -- there are a handful of issues here

1. SAFETY docs are missing/incomplete
2. We need to convert panic to Err
3. This code is hairy enough to warrant two functions. One function that returns an iterator over sample genotypes. And some "sample genotype" type that itself creates an iterator over the optional allele IDs. Then the current fn is just a flat mapping over the genotypes iterator. Normally I'd call the second function syntax sugar that shouldn't be in the lib, but I think dealing with unsafe, C, and bit shifts means that sugar functions actually pull their weight here.

[molpopgen]

(The reason a genotypes iter is a good thing is that combining it with enumerate gives downstream code a way to break input into sample sets.)

[laggycomputer]

We might want a note here for why we're not using safe Rust-level htslib