Fix size_hint on Skip

[lilyball]

If the upper bound of the wrapped iterator has saturated at
uint::max_value, keep it there. It may actually represent an upper bound
that is higher.

r? @thestinger

[bluss]

I thought infinite iterators should use None for upper bound (like Counter). Does Some(uint::max_value) mean anything else than the literal value?

[thestinger]

@blake2-ppc: you're right - if they can't represent the upper bound as uint it should be None, it's the lower bound that gets clamped to uint::max_value

[lilyball]

@thestinger I thought we had decided that None meant unknown, not unbounded.

I've been giving some thought as to whether we should actually use an enum for this case, to distinguish Unknown, Unbounded, and Bounded(uint), but I've been holding off because I wasn't sure it was worth the additional complexity.

[thestinger]

The lower and upper bounds are limits, so if it can't be represented in a uint it's unknown because it's not bounded by uint::max_value.

[lilyball]

Fair enough. I don't remember anymore what led me to believe we had decided that uint::max_value should be pegged. It's possible I was just mis-remembering something else.

[thestinger]

@kballard: the lower bound should be pegged to uint::max_value, I think that's what we discussed before

[lilyball]

@thestinger I feel like the idea was that when adapting an iterator in a fashion that would raise the upper bound (e.g. chain()), the upper bound would be saturated at uint::max_value. And because of that, anything that reduces the upper bound would treat uint::max_value specially as that may be an indication of saturation rather than an exact bound.

In any case, since you don't think this is the approach we should take, then we may have to fix the iterators that increase the upper bound to detect overflow and flip to None instead of merely saturating. This needs the .checked_add() that @huonw was talking about in IRC yesterday (which we can implement trivially for primitive integral types the same way saturating_add() is implemented; in fact I was originally considering making .saturating_add() return (Self, bool) but decided not to in order to make it simpler to use).

[thestinger]

It's not necessarily that I don't think it's the approach we should take, but right now the second element is defined as the upper bound and if the iterator yields more elements it's not a bound.