Why Normalize VersionRange?

A VersionRange represents set of segments of package versions. Different VersionRange can represent the same set of segments.

For example, consider the package pkg:npm/foobar with the following versions: ["1.0", "2.1", "2.2", "3.0", "3.1", "5.0"].
We can represent certain segments using the vers expression vers:npm/<=2.2|>=3.0|<3.1|5.0.
This can also be represented as:

• vers:npm/>=1.0|<3.0|>=3.0|<3.1|5.0
• vers:npm/<3.1|5.0
• vers:npm/>=1.0|<=2.2|>=3.0|<3.1|5.0

These different representations make it difficult to validate whether two different VersionRange represent the
same versions of a package.

To effectively compare these ranges, we need to normalize them. The idea is that all the vers referring to
the same set of package versions should normalize to an identical VersionRange.
To achieve this, we take a vers along with all the versions of the package and generate a new vers
such that it contains not arbitrary version segments but only the longest contiguous segments of versions, leading to the same VersionRange expression which is identical for a particular set of versions.

If we apply this normalization to the above example of pkg:npm/foobar:

• vers:npm/<=2.2|>=3.0|<3.1|5.0 would normalize to vers:npm/>=1.0|<=3.0|5.0

The same normalization applies to other VersionRange since they all refer to the same set of versions,
they will all normalize to the exact same VersionRange:

• vers:npm/>=1.0|<3.0|>=3.0|<3.1|5.0 => vers:npm/>=1.0|<=3.0|5.0
• vers:npm/<3.1|5.0 => vers:npm/>=1.0|<=3.0|5.0
• vers:npm/>=1.0|<=2.2|>=3.0|<3.1|5.0 => vers:npm/>=1.0|<=3.0|5.0

• Support normalization of vers range expression using all the available package version.
• Support VersionRange from snyk advisory and discrete version.
• Various bug fix in from_gitlab_native from_gitlab_native can't properly parse range expressions for Composer, Maven and NuGet #136
• Bug fix Incorrect __contains__ resolution in VersionRange #137
• Fixes Incorrect affected package in composer advisories vulnerablecode#1516