## Summary
This PR has breadth, but not depth. This adds 3 new `eslint` rules. The
first two protect against the use of code generated from strings (`eval`
and friends), which will not work client-side due to our CSP, and is not
something we wish to support server-side. The last rule aims to prevent
a subtle class of bugs, and to defend against a subset of prototype
pollution exploits:
- `no-new-func` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-new-func
- `no-implied-eval` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-implied-eval. Note that this
function implies that it prevents no-new-func, but I don't see [test
cases](https://github.com/eslint/eslint/blob/main/tests/lib/rules/no-implied-eval.js)
covering this behavior, so I think we should play it safe and enable
both rules.
- `no-prototype-builtins` to prevent accessing shadowed properties:
https://eslint.org/docs/latest/rules/no-prototype-builtins
In order to be compliant with `no-prototype-builtins`, I've migrated all
usages and variants of `Object.hasOwnProperty` to use the newer
[`Object.hasOwn`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn).
/api/_xpack/usage was added as a target for 6.4.0 but it will not be
used. Instead, the /api/stats response will include usage info on
everything that gets registered with the usage service in
/src/server/usage
/api/_kibana/v1/stats is a GET API that was added in 6.2, during a point
where we thought providing usage stats through a public API would be OK
for capturing internally, with the benefit of having it be visible.
However, we've pivoted away from that idea because it doesn't line up
too well with the existing flow of data, where usage stats are combined
with the "Kibana stats" such as process uptime and number of requests.
We want to shift how we collect stats from Kibana, but it will be
gradual. It might be a while before we have an architecture that makes
sense for a standalone public API for the usage stats
This endpoint was never documented, and isn't used anywhere in the code.
It does incur a maintenance cost though.
Therefore, instead of waiting for a next major version to remove this
API, I'm removing it for 6.4. It will be marked in the release notes as
a breaking change. Since it was never documented, it should not provide
a problem.
