fix https://github.com/elastic/kibana/issues/192052
## Summary
Internal APIs will be
[restricted](https://github.com/elastic/kibana/issues/163654) from
public access as of 9.0.0. In non-serverless environments, this breaking
change will result in a 400 error if an external request is made to an
internal Kibana API (route `access` option as `"internal"` or
`"public"`).
This PR allows API owners of non-xpack plugins to run their `ftr` API
integration tests against the restriction and adds examples of how to
handle it.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
Note to reviewers: The header needed to allow access to internal apis
shouldn't change your test output, with or without the restriction
enabled.
### How to test the changes work:
#### Non x-pack:
1. Set `server.restrictInternalApis: true` in `test/common/config.js`
2. Ensure your tests pass
#### x-pack:
1. Set `server.restrictInternalApis: true` in
`x-pack/test/api_integration/apis/security/config.ts`
2. Ensure the spaces tests pass
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/83409
Use a permanent cache (`public, max-age=365d, immutable`) for
translation files when in production (`dist`), similar to what we're
doing for static assets.
Translation files cache busting is a little tricky, because it doesn't
only depend on the version (enabling or disabling a custom plugin can
change the translations while not changing the build hash), so we're
using a custom hash generated from the content of the current
translation file (which was already used to generate the `etag` header
previously).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
