feat: create SparseRepoData from byte slices

[aochagavia]

This is a breaking change, because it introduces a lifetime parameter for SparseRepoData. If that's undesirable, maybe we could create an inner type (e.g. SparseRepoData2) wrapped by two outer types (e.g. MemmappedSparseRepoData and ByteSliceSparseRepoData). We ended up using Bytes with a self-referential borrow to get rid of the lifetime entirely, so now the change is no longer breaking 🎉.

I also took the liberty to switch from stable to unstable sorting, which has better performance characteristics. If you'd rather leave things as they are now, I can drop the commit.

Fixes #619

[baszalmstra]

I also took the liberty to switch from stable to unstable sorting, which has better performance characteristics. If you'd rather leave things as they are now, I can drop the commit.

Did you profile this with a real-world scenario? Most repodata.json is already sorted but just on a slightly different key therefor I didn't think this would matter much.

Im also a little hesitant to add randomness to the repodata.json. I don't think the order of the records in the file matters much but I am not completely sure.

This is a breaking change, because it introduces a lifetime parameter for SparseRepoData.

Look at the changes, can we use a 'static lifetime for the memory mapped data, which would still allow use to pass it around in Arc<SparseRepoData<'static>>s?

[aochagavia]

Look at the changes, can we use a 'static lifetime for the memory mapped data, which would still allow use to pass it around in Arc<SparseRepoData<'static>>s?

That's indeed possible (in fact, I had to manually specify the 'static lifetime somewhere and it worked). On the other hand, it might be more user friendly to keep SparseRepoData as it is now and introduce an additional ByteSliceRepoData<'a>. Both structs would internally use the same code, and users would be spared the pain of updating and having to specify lifetimes everywhere (which might even be confusing for people). What do you think?

Did you profile this with a real-world scenario? Most repodata.json is already sorted but just on a slightly different key therefor I didn't think this would matter much.

I haven't profiled it. It's just that the stable version allocates half the size of self, according to the docs, so it feels "more correct". The docs even recommend using sort_unstable if you can get away with it (unless you really need a stable sort, that is). Also good to know, the sort is deterministic (it uses a constant random seed).

I don't think it really matters in practice, so let me know if you'd rather have me drop the commit 😉

[baszalmstra]

Both structs would internally use the same code, and users would be spared the pain of updating and having to specify lifetimes everywhere (which might even be confusing for people). What do you think?

Lets do that, it feels more ergonomic.

I don't think it really matters in practice, so let me know if you'd rather have me drop the commit.

I'm also fairly certain the order doesn't matter. So let's just leave it in. 🙉

[aochagavia]

Rebased and figured out how to make the change non-breaking. This is now ready for review!

[baszalmstra]

One tiny little comment but otherwise LGTM