For example, the name extracted from a requirement of
"python3.10dist(fonttools[unicode])[>= 4.10]" was sometimes
"python3.10dist(fonttools" instead of the expected
"python3.10dist(fonttools[unicode])".

Code parsing such strings existed in many places, it now exists only
in 2 places, a perl version in Resolve.pm and a C version in URPM.xs.

Both codes used to handle both "foo >= 0" and "foo[>= 0]" but at least
the perl code seems to only call it on provides/conflicts/obsoletes
which are always using the second form so the support for it was
dropped from the perl version for the sake of simplicity.

Thus fixing "invalid line <@provides for huge pkgs"...
The fix in 5.221 was fixing emiting provides in synthesis for pkgs with
lot of provides, but neither URPM or urpmi testsuite uses such a pkg and
didn't catch that having those provides in synthesis would break reading
synthesis.
See commit 950d56e991d307b9b60bde8f51920bee3d1bc61c

Rationale for the high bump:
Fixing the sorting on http://matrix.cpantesters.org/?dist=URPM

We switched to version object because that enables to have test versions to
test on CPAN testers (eg: 5.21.1, 5.21.2, .. .before releasing 5.22).
So we switched from 5.22 to v5.22.
See commit 7677ec9fe63dd33d125d19e1f9225c5b4d6d5f4a
See https://rt.cpan.org/Public/Bug/Display.html?id=127142

However v5.22.0 is less than 5.21 (interepreted as a floating point by perl):
perl -Mversion -E 'say version->new("v5.22")->numify'
5.022000

So we bumped the version from v5.28 to a much higer one.

However commit a58cf629be7e0d0512d6e1fd95c5004fb833c8c3 had a typo.
It clearly says we wanted to bump to v5.212.0, as 5.21 was the greatest
old-style version.

But it actually bumped to v5.122 whereas 5.122000 < 5.21:
$ perl -Mversion -E 'say version->new("v5.122")->numify'
5.122000

Rationale:
when generating synthesys, there's one new pkg whose provides were not
emitted in synthesis because its provides would overflow the static
buffer by 2 bytes:
"buffer overflow: 131074 < 131072 for provides"

Also log when the buffer would be too small instead of silently ignoring
the issue.

The offending package is golang-github-azure-sdk-devel which has 2707
provides which translates to a 131074 characters line in synthesys.

commit 3fac0be4adab0ee63b6473d613982b418cc7ab92 was not enough in iurt
case.
We must also ignore SRPM provides.

Rationale:
Since rpm-4.16+, rpmlib adds NEVR provides for all packages that would
be built into source rpm.

Thus we hit:
"installed package gdb-minimal-10.2-2.mga9.x86_64 is conflicting with gdb-11.1-1.mga9.src"
Because of "Conflicts: gdb-headless[> 10.2-2.mga9]"
Because gdb-11.1-1.mga9.src.rpm provides "gdb-headless = 11.1-1.mga9"