Upgrade fastzip to v0.1.9, fixes invalid timestamps

What does this MR do?

Upgrades fastzip to v0.1.9, fixing an issue where no timestamp is encoded for some zip entries.

Why was this MR needed?

Some Zip entries were missing modification timestamps.

What's the best way to test this MR?

Creating a cache/archive, with at least 2 compressible files and using zipinfo will reveal that previously, we were not storing the native DOS-style modification timestamp, nor the Extended Timestamp that appears in the "Extra Data" of a ZIP entry.

I've used this job to test with (with the shell executor, on MacOS):

.gitlab.ci.yml

variables:
  FF_USE_FASTZIP: "true"

stages:
  - upload
  - download

upload_artifact:
  stage: upload
  script:
    - mkfile -n 10m file1
    - mkfile -n 10m file2
    - touch -m -d "2020-01-01 00:00:00" file1
    - touch -m -d "2020-01-02 00:00:00" file2
  artifacts:
    paths:
      - file1
      - file2

download_artifact:
  stage: download
  script:
    - ls -al
    - stat file1
    - stat file2

Before this change

If you download the artifact and inspect with infozip, the last modified timestamp will read "1980 000 0 00:00:00".

The second job's files won't have 2020-01-02 00:00:00 as the modification date, but todays date and time.

With this change

Downloading and inspecting the artifact with infozip with have both DOS and Unix extra timestamps with 2020-01-02 00:00:00.

The second job's stats calls with contain 2020-01-02 00:00:00 as the last modification date.

What are the relevant issue numbers?

Closes #28928 (closed)