Build performance: Avoid preview on mainline builds, and cache dependencies

[holly-cummins]

As a result of #299, our builds have got atrociously slow. We were already doing three npm installs per build, so let's see if caching helps.

I also noticed we were doing a 5m upload of artifacts for previews, even on mainline builds.

[github-actions]

🚀 PR Preview 85a605b has been successfully built and deployed to https://extensions-quarkus-pr-300-preview.surge.sh

[holly-cummins]

It looks like the cache flag on the setup-node step doesn't cache as much as you'd hope. I'm finding the docs a bit unclear, but I think it's caching global dependencies only.

As an alternative, we can cache the whole node_modules directory. This has some risk, but let's try it until we hit problems.

[holly-cummins]

I think I've just tripped over the risk. Some of the gatsby code does this:

cp ./node_modules/gatsby-page-utils/dist/apply-trailing-slash-option.js ./node_modules/gatsby-page-utils && gatsby build

... and then falls over. I'll do a more restricted cache, just of the dependency that's very slow.

[holly-cummins]

Even with a populated ~/.npm folder and --prefer-offline, the npm ci phase was still taking around seven minutes. The cache was being downloaded, but it didn't seem to affect the speed of the github dependency. I've switched to using a binary package of the forked dependency, and npm ci is down to 1m 16s on a 'clean' run, and (disappointingly) the same on a run where a cache exists. That's basically the same as it was before all these changes, but at least it's not worse.

[holly-cummins]

The build seems to be a bit faster without the cache and composite action, so I've removed it.