Fix broken simplification of prerelease constraints

[sigurdm]

Fixes: #3057
Fixes: #3038
Fixes: #3028

I am not sure what was exactly meant by having the case (range.min.isPreRelease && range.max == range.min.nextBreaking) but it seems not. quite right.

>=0.9.0-1 < 0.10.0 would get translated to ^0.9.0-1. But ^0.9.0-1 in pub_semver is the same as >=0.9.0-1 < 0.10.0-0, and that is what gets captured by the first part of the condition: range.max == range.min.nextBreaking.firstPreRelease.

[jonasfj]

>=0.9.0-1 < 0.10.0 would get translated to ^0.9.0-1. But ^0.9.0-1 in pub_semver is the same as >=0.9.0-1 < 0.10.0-0, and that is what gets captured by the first part of the condition: range.max == range.min.nextBreaking.firstPreRelease.

I imagine this was intended to catch the case where: >= 0.10.0-1 <0.10.0 can be translated to ^0.10.0-1.

I'm guessing we'll need something like: (requiring us to add Version.withoutPreRelease or auxiliary function)

    if (range.max == range.min.nextBreaking.firstPreRelease ||
        (range.min.isPreRelease && range.max == range.min.withoutPreRelease)) {

@sigurdm Does that make sense?

EDIT: Resolved in chat, no this doesn't make sense.

[jonasfj]

I think this is correct, but that we could probably fix the bug that is the original intent here, if we wanted to -- see previous comments.