Spaces mapping

[legrego]

This PR accomplishes the following:

1. Introduces the concept of a URL Context (see below)
2. Registers the current Space on each incoming request (for eventual use by the Saved Objects Client and others)
3. Shows the Space Selector (i.e., "screen door") when navigating to the Kibana root

URL Context

The URL Context is essentially the Space's display name, from the URL perspective. The URL Context is automatically derived from the Space's name, but can be manually adjusted by the user.
Example:
Space Name: My Awesome Space
URL Context: my-awesome-space

When using Kibana within this space, the URL will look similar to: http://kibana.home/s/my-awesome-space/app/kibana.

Changing the URL Context of an existing space will effectively break existing links and bookmarks, so we display a warning message when you attempt to do this, but we don't currently prevent the change.

TODO

• Additional testing once the overall approach is validated.
• Additional UI work to improve the UX. Functionally this is pretty close.
• Integrate this work with [Spaces] Space Avatar with selector in main Kibana menu #18609

[kobelb]

Awesome job, I really like the concept and implementation of the UrlContext

[kobelb]

Do we still need this?

[legrego]

There might be a better way to do this, but I need the spaces var here so that angular can inject it here. The default isn't really used, but I make use of the override available here.
This allows the Space Selection screen to have all the information it needs to render, instead of having the client make another ajax call once the page loads. We'd end up with another loading screen while we waited for the Space Selector to load the available spaces.

[kobelb]

Interesting... so if we don't define it here we can't provide it via the render call? That's super weird...

[legrego]

Yeah - the Angular controller would actually fail because there isn't a "spacesProvider" registered with the system. At least that's what happened with my testing...I could be overlooking a better solution.

[kobelb]

I've seen crazier things, it works for me!

[kobelb]

nit: Cpntext and rewrire are misspelled

[kobelb]

Are we only using _spaceUrlContext below? I've seen usages of Weakmap to do similar things without "leaking" the variable, perhaps we could do something similar here?

[legrego]

For now, this is the only place it's used, but the Saved Objects Client will eventually need to have the space available to it. I haven't thought about what that will look like yet, but I can make it a Weakmap for now, and change it later if needed.

[kobelb]

I wonder if we could expose the UrlContext on the request itself, that way it's more generic?

[legrego]

hmm, we certainly could.
For the Saved Objects Client, I imagine that we'll be augmenting the reads/writes to include the new spaceId property on the index mapping, so we will need a way to lookup the spaceId from the URL Context. I'm worried that decoupling the URL Context from Spaces too much will make that translation confusing to follow.

I also thought about just storing the spaceId instead, but that introduces a lot of unnecessary overhead on each request (because we have to look it up), even if the space id isn't needed for it.

[kobelb]

LGTM