Build fails with it, let's see if we need it.

Sometimes, there are untracked files left in the dl directory, which
another job already commited in the DL cache. git pull will then fail
becaue it won't overwrite untracked files.

By first pulling (which will fail), then commiting and pulling again we
will avoid this situation.

Another build job might since have commited its dl-cache hence do a pull
before we commit our dl cache.

Makefile:32: *** Warning: GLUON_BRANCH has been deprecated, please set GLUON_AUTOUPDATER_BRANCH and GLUON_AUTOUPDATER_ENABLED instead.

So let's use the new variables now.

The git push in after_script didn't succeed because of failing
authentication. As the authentication succeeds in before_script, it is
likely the SSH agent from before_script doesn't run in after_script.
Likely because a new shell is spawned. Hence, start it again in
after_script.

This will enable the download cache in the package stage, which
currently spends a lot of time with downloading things.

After we can now build with BROKEN, the build for raspi4 should work.

People asked for the Raspberry Pi 4, but it's currently broken and hence
is not build if one doesn't set BROKEN. Thus, allow us to set BROKEN for
some targets to allow these images to be built.

This reverts commit 0df9f251. The target
doesn't seem to be supported, the build failed:

  make[1]: Leaving directory '/builds/firmware/site-ffs/gluon/openwrt'
  Please set GLUON_TARGET to a valid target. Gluon supports the following targets:
   * ar71xx-generic
   * ar71xx-tiny
   * ar71xx-nand
   * ath79-generic
   * brcm2708-bcm2708
   * brcm2708-bcm2709
   * ipq40xx-generic
   * ipq806x-generic
   * lantiq-xrx200
   * lantiq-xway
   * mpc85xx-generic
   * mpc85xx-p1020
   * ramips-mt7620
   * ramips-mt7621
   * ramips-mt76x8
   * ramips-rt305x
   * sunxi-cortexa7
   * x86-generic
   * x86-geode
   * x86-legacy
   * x86-64
  Makefile:158: recipe for target 'config' failed

Previously, we've cached staging_dir in the gluon/openwrt subdirectory.
But this doesn't really work properly because of gitlab's submodule
behaviour. It will first extract the cache and then update the
submodules.

Because the cached directory resides inside the gluon submodule, it will
be deleted upon submodule checkout. By putting the cache in a directory
outside the submodule we can avoid this. We will then simply symlink the
cached directory to the desired destination such that it is found during
the build.