kmer_hash does not preserve sized_range properties correctly

[MitraDarja]

When the underlying range is std::list while using kmer_hash the sized_range property is not preserved as it should be.

// According to kmer_view sized_range properties is preserved and for other type of ranges (e.g. std::vector) it is true, but not for std::list???
    std::list<seqan3::dna4> text5{'A'_dna4, 'C'_dna4, 'G'_dna4, 'T'_dna4, 'A'_dna4, 'G'_dna4, 'C'_dna4};
    auto v5 = text5 | ungapped_view;
    seqan3::debug_stream << std::ranges::sized_range<decltype(text5)>; //prints: 1
    seqan3::debug_stream << std::ranges::sized_range<decltype(v5)>;    // prints: 0

[rrahn]

Ok the problem is the following. All our views inherit from std::ranges::view_interface. This adds member functions based on some pre-conditions. For example it adds a size member function if the sentinel and the iterator model sized_sentinel_for. But there are 2 different ways to check if a range is a sized range. Either it offers a size member function which returns the size in constant time, or if this is not given it checks if the range has sized_sentinel_for sentinel,iterator pair. Since it would be false to just use size of ther unterlying range for the view interface it uses sized_sentinel_for condition to check if the ranges is sized. This not true for lists anymore.

To fix this:

• add an explpict size member function to the kmer_hash view which is only enabled if the underlying range is sized
• the size member function returns std::ranges::size(urng) - shape.size() + 1
• test that the size is 0 if the underlying range is empty or the shape is larger than the underlying range
• add a changelog entry

[MitraDarja]

@rrahn Because the bug appeared in the test cases I edited (#1722), I would like try to fix it, should I wait with it until the next iteration? Plus can I include the fix in the mentioned PR or should I create a separate one?

I just added the fix to my PR. 😃

[rrahn]

Thanks for working on this. In general I would make it a separate PR in teh future. But for now this is ok.

[rrahn]

fixed by #1722