Upload cached frontend stable packages

What does this MR do and why?

The time spent doing a yarn install with nothing in node_modules can result in anywhere from 5m to 20m.

On master, we currently upload a cache of the frontend assets to save time.

.caching:rules:cache-assets:
  rules:
    ...
    - <<: *if-dot-com-gitlab-org-default-branch # <== if there are asset changes in master, upload the package in the `cache-assets:production` job
      changes: *assets-compilation-patterns

This results in MRs towards master, and future master pipeline runs to not having to re-compile the cache, resulting in the compile-production-assets taking only seconds as opposed to minutes

This MR adds a rule to ensure that all stable branches publish their own frontend asset packages.

This will result in all future stable branch runs (17.11+; where a cache exists) to shave off minutes per-pipeline. This will also shave minutes per-pipeline for backport MRs targeting those stable branches, where frontend assets have not changed.

Note: This also affects security stable pipelines. Security stable branches will push their own cached assets as well.

References

Closes gitlab-com/gl-infra/delivery#21130 (closed)

Post-merge

• backport to 18.1 !195999 (merged)
• backport to 18.0 !196001 (merged)
• backport to 17.11 !196002 (merged)

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.