Don't compute integrity when network restricted

[arcanis]

It seems that git repositories have no integrity in the lockfile. This causes issues with --offline, since the current try will try to regenerate it (even if it won't succeed), and crash because it cannot access the network.

There's two issues there:

• Git repositories have no integrity. Even if we allow it, it should be marked in the lockfile (for example by setting null), in order to let Yarn know that the integrity couldn't be computed at all.

• When working with --offline, we shouldn't try to generate the integrity if it doesn't exist. This is what this PR fixes.

cc @imsnif who worked on the integrity field.

[imsnif]

@arcanis - is it possible to see a test case (or some repro) that this PR fixes?

[arcanis]

@imsnif It can't be easily tested since it involves git repositories 😞

Basically this is the repro:

$> echo yarn-offline-mirror ./offline-mirror > .yarnrc

$> yarn add yarn@[email protected]:yarnpkg/yarn
# The sha hash is missing from the lockfile

$> yarn cache clean && rm -rf node_modules

$> yarn --offline
# Since the sha hash is missing, Yarn was trying to regenerate it and failed

[imsnif]

So first - good catch! Turns out this is actually not unique to github deps, but to all deps that do not have an integrity field in yarn.lock (eg. when updating from an old yarn version).

Because of this, adding a test was possible. I added one that checks this basic scenario and fails if we revert your change. Wdyt @arcanis?

[arcanis]

Oh nice! Looks great, thanks 👍