[optimize] Use <base> tag for predicatable relative paths

[spalger]

In Kibana 4.3 we added the server.basePath setting to enable better support for running Kibana somewhere other than the root of a web server (eg. /logs/kibana/app/kibana instead of /app/kibana). Unfortunately using this configuration triggers a re-optimization because the basePath was previously being written into the bundles in order to ensure compatibility in all scenarios. The optimization process has gotten longer and more painful over the years, and we are working to remove it entirely, so we needed a way to support basePath without needing to write it into the bundles.

Starting in 6.1 Kibana will use the <base> tag to adjust the way that relative URLs are resolved, ensuring that URLs at any page are resolved relative to the basePath. In order to support this, all href, src, and API call that is currently using relative urls (including hash urls) needs to be updated to include all path segments following the basePath.

This is a pretty major breaking change for anyone creating or storing relative URLs, so

to the HTML and JavaScript where relative URLs should be resolved from. Doing this prevents us from needing to rebuild assets, and allows us to support basePath in the future when we are no longer optimizing in production, but is a

If you are storing relative URLs in markdown panels, URL field formatters, or source code then you will need to migrate to a new relative "format".

HTML and JS

Relative URLs previously resolved based on the current page but now resolve relative to the basePath. To keep links working correctly, add all necessary path segments first /:

// ✅ correct
$http.get('api/plugin/things');
<img src="plugins/kibana/images/logo.png">
<a href="app/kibana#/dashboard">

// 🚫 incorrect
$http.get('../../api/plugin/things');
<img src="/plugins/kibana/images/logo.png">
<a href="#/dashboard">

CSS

URLs resolved in CSS are not impacted by <base> and therefore should not require any modification.

[spalger]

This code should be useful in the future, but we're going to go forward with #14007 for the time being, until we are ready for a massive breaking change in Kibana URLs (hopefully in conjunction with #11015)