Insert/remove range with bounds

[oliverdding]

Implementation of insert_range and remove_range functions that accept the RangeBounds trait instead of a Range struct.

This PR fix #5 and #113.

Done:

• Switch inner parameters to RangeBounds
  • insert_range
  • remove_range
• Fix boundary condition in insert_range/remove_range
• Add more test cases
• switching to RangeInclude on the Container and Store
  • insert_range
  • remove_range

[oliverdding]

Hi @Kerollmops

Thanks for your reviewing!

Recently I might have no time to code since I'm on my way to travel 👻. But I would come back ASAP.

[oliverdding]

Hi @Kerollmops
Sorry for late.
I've marked the conversation resolved if I accepted your advice or it's duplicate, leaving some topics to talk about.

[Kerollmops]

Thank you very much for your changes, can you please change your code a little bit, please?
I think I will merge your code just after :)

[oliverdding]

Hi @Kerollmops
I have finished all the jobs here ;)

And I just want to mention the util::convert_range_to_inclusive, which is done like this:

pub fn convert_range_to_inclusive<R>(range: R) -> Option<RangeInclusive<u32>>
where
    R: RangeBounds<u32>,
{
    let start: u32 = match range.start_bound() {
        Bound::Included(&i) => i,
        Bound::Excluded(&u32::MAX) => return None, // must exit here
        Bound::Excluded(&i) => i + 1,
        Bound::Unbounded => 0,
    };
    let end: u32 = match range.end_bound() {
        Bound::Included(&i) => i,
        Bound::Excluded(&0) => return None, // must exit here
        Bound::Excluded(&i) => i - 1,
        Bound::Unbounded => u32::MAX,
    };
    if end < start {
        return None;
    }
    Some(start..=end)
}

In this way we can idiomatically avoid the saturating_sub with simplier logic, and I think you would like it ;)

[Kerollmops]

It is indeed a lot better @oliverdding, I love what you've done here.
I am merging all of that right now!