ci: Run compatibility test ignoring lockfile

[legobeat]

This adds an additional run of tests against a state where yarn.lock is removed prior to the installation. This is intended to catch e.g. regressions and mislabeled breakage in updated transitive dependencies.

This will map more closely to what users get when installing the released package from registry.

Left out the intermediate versions of node as an optimization. The normal cache is still used since significant overlap is expected.

Potential future improvements

• Run test against built package under another package manager (yarn v1 and/or npm)
  • Ensure there aren't implicit dependencies on yarn berry
  • Would allow throwing on breakages in engines without adding a plugin

[legobeat]

  ➤ YN0013: │ 10 packages were already cached, 743 had to be fetched
  ➤ YN0019: │ 199 packages appeared to be unused and were removed

:dancers:

In case the overhead in the extra loading of packages is not palatable, I think most situations would be covered by dropping tested versions to only the lowest 16.

[legobeat]

@Mrtenz

One example scenario:

• Package alpha@2.0.1 is based on this template and has a direct pinned dependency on foreign package beta@1.2.3, in turn depending on ceta@^4.5.6
• ceta publishes 4.6.0, causing breakages in the way alpha uses beta.

This breakage would not get caught in CI tests nor developer environments before this change until someone explicitly causes a lockfile bump, but could trigger breakage for users and dependents on alpha from the release of ceta.