These no-op default exports have served one or both of these purposes:

1. Preventing `babel-plugin-rewire` from generating an invalid default
   during karma tests;
1. Working around the `import/prefer-default-export` ESLint rule for
   files which only have one named export.

As we recently finished migrating all relevant specs from Karma to Jest,
the first purpose is no longer necessary (with two exceptions, see
below).

The second purpose will become unnecessary once the [RFC][1] to prefer
named exports to default exports is implemented.

As such, this commit removes almost all no-op default exports, and adds
explicit `eslint-disable-next-line` directives (which can be removed
once the RFC is implemented).

---

This work was achieved in a few steps. First, the default exports
explicitly marked as `babel-plugin-rewire` workarounds were removed.

This was achieved via this command:

    rg --color=never -l0 "// prevent babel-plugin-rewire" \
        | xargs -0 \
        perl -0pi -e \
        's/\n+\/\/ prevent babel-plugin-rewire[^\n]*tests'\
    '(?:\nexport default \(\) => {};)?//mgs'

The documentation describing this workaround was then removed by hand.

Unfortunately, two files still participate in Karma tests, and still
need this workaround, so these were reverted manually. Those files (at
the time of writing) are:

    app/assets/javascripts/monitoring/stores/actions.js
    app/assets/javascripts/monitoring/stores/getters.js

Then, all additional no-op default exports were removed with this
command:

    rg --color=never -l0 -F "export default () => {};" \
        | xargs -0 perl -0pi -e 's/\n+export default \(\) => {};//mgs'

Since the `import/prefer-default-export` ESLint rule is still in place,
the files violating it have to disable it explicitly.

With the [RFC][1] to prefer named exports to default exports receiving
wide approval, it makes sense to mark these current violations
_explicitly_ with `eslint-disable-next-line` directives, rather than
_implicitly_ via the no-op default export hack.

The benefit of this approach is that when we disable the
`import/prefer-default-export` rule globally for the RFC, ESLint will
warn about all of these now-unnecessary directives. This will make it
much easier to address all of them (perhaps even automatically, via
`--fix`!).

[1]: https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/20