Apparently we hit a very unlikely case that lead to our builds to be
unstable:

1. The `@vue/compiler` uses a small LRU cache with the latest 100 vue
   files it parsed.
2. It uses a `hash(filename + source + constant)` for the key of the
   cache. The hashing function has 2^32 different outcomes

With our code base we have a pure chance of a hash collision of 1.3 per
thousand. This collision happens with the two files at this commit:
850d6792

- app/assets/javascripts/work_items/components/work_item_state_badge.vue
- app/assets/javascripts/profile/components/user_achievements.vue

Now two more conditions needed to be fulfilled for it to become
problematic:

1. The two files needed to be parsed within a short period, otherwise
   the collision in the LRU cache would have been avoided. This explains
   why not every job was failing.
2. In order for the jobs to fail, the colliding files needed to use
   relative imports. If `work_item_state_badge.vue` accidentally loaded
   the content of `user_achievements.vue`, the relative import
   `./graphql/get_user_achievements.query.graphql` didn't exist. Vice
   versa if `user_achievements.vue` loaded the wrong contents, the
   relative import `../constants` didn't exist.

If neither of the colliding files would had relative imports, the
components might have been swapped silently, leading to potentially
undetected runtime errors.

We mitigate this issue by patching the hashing of the key to be:
`hash(a) + hash(b) + hash(c) + hash(d)` rather than `hash(a+b+c)`. This
decreases the likelyhood of collisions from `1.3 * 10^-3` to
`2.3 * 10^-9`, making it 570000 times less likely to hit a collision.

We probably should follow this up with an upstream contribution, so that
other large vue projects are not hit by this.