Fail fast on integer overflow

[iamdanfox]

Before this PR

In PDS-235827, we've encountered some version strings which are constructed by doing x.y.yymmddhhmm. It turns out this was fine last year, but now produces numbers like 1.1.2201051644 which is larger than Integer.MAX_VALUE. The consequence is a bit scary - in the latest version of sls-version-java we'll actually tolerate these, but internally when we store the .patchVersionNumber(groups.groupAsInt(3));, the giant integer overflows to becoem a negative number so they SORT WRONG.

After this PR

==COMMIT_MSG==
OrderableSlsVersion.valueOf will now refuse to interpret a version string containing a number greater than Integer.MAX_VALUE as a valid orderable version.
==COMMIT_MSG==

The reason I want to fail hard rather than try to relax this is because the abstract SlsVersion class imposes these fun methods which all mention integers, and I have no interest in causing an ABI break just for this.

    public abstract int getMajorVersionNumber();

    public abstract int getMinorVersionNumber();

    public abstract int getPatchVersionNumber();

    public abstract OptionalInt firstSequenceVersionNumber();

    public abstract OptionalInt secondSequenceVersionNumber();

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

OrderableSlsVersion.valueOf will now refuse to interpret a version string containing a number greater than Integer.MAX_VALUE as a valid orderable version. Previously they would be parsed, but have surprising sorting behaviour.

Check the box to generate changelog(s)

• Generate changelog entry

[carterkozak]

pedantic nit: We may want to extract this to a integerOverflow(String,int,int); function to cut negative test data out of hot paths for better inlining

[carterkozak]

Thanks!

[svc-autorelease]

Released 1.3.0