Store static contexts on the variant rather than the page

After a discussion with @effulgentsia, I'm going to work on allowing variants to also store static contexts.
While this might make the UI more confusing in the short term, it also doesn't require an upgrade path.

Here we go!
This still has some @todos to fix, just want to get a patch up.

Touched up more. Done for the day.

1. +++ b/page_manager.routing.yml
   @@ -85,28 +85,28 @@ page_manager.access_condition_delete:
   +    _entity_access: page_variant.update
   ...
   +    _entity_access: page_variant.update
   ...
   +    _entity_access: page_variant.update
   

   So I know we're adding the page_variant entity into this stuff, but I question whether that entity's access should be responsible for these routes. Justification?

2. +++ b/page_manager.services.yml
   @@ -9,11 +9,9 @@ services:
   +  page_manager.context_mapper:
   +    class: Drupal\page_manager\ContextMapper
   

   Yeah for the moment, we should move this to CTools in a follow up.

3. +++ b/src/ContextMapper.php
   @@ -0,0 +1,55 @@
   +  public function getContextValues(array $context_configurations) {
   +    $contexts = [];
   +    foreach ($context_configurations as $name => $context_configuration) {
   +      $context_definition = new ContextDefinition($context_configuration['type'], $context_configuration['label']);
   +      if (strpos($context_configuration['type'], 'entity:') === 0) {
   +        $context = new EntityLazyLoadContext($context_definition, $this->entityRepository, $context_configuration['value']);
   +      }
   +      else {
   +        $context = new Context($context_definition, $context_configuration['value']);
   +      }
   +      $contexts[$name] = $context;
   +    }
   +    return $contexts;
   +  }
   

   This looks really really great. ++

4. +++ b/src/Entity/Page.php
   @@ -112,43 +121,6 @@ class Page extends ConfigEntityBase implements PageInterface {
   -  public function getExecutable() {
   -    if (!isset($this->executable)) {
   -      $this->executable = $this->executableFactory()->get($this);
   -    }
   -    return $this->executable;
   

   YAY!

5. +++ b/src/Entity/Page.php
   @@ -257,41 +229,18 @@ public function getAccessLogic() {
   +  public function addContext($name, ContextInterface $value) {
   +    $this->contexts[$name] = $value;
   

   Is this used in the event?

6. +++ b/src/Entity/Page.php
   @@ -351,23 +300,34 @@ public function variantSortHelper($a, $b) {
   +    foreach ($this->getPluginCollections() as $plugin_config_key => $plugin_collection) {
   +      $this->set($plugin_config_key, $plugin_collection->getConfiguration());
   +    }
   

   I thought we had a trait that used to do this in core. :-(

7. +++ b/src/Entity/PageVariant.php
   @@ -232,11 +241,9 @@ public function getVariantPluginId() {
   +  public function getPage() {
   

   I am totally on board with making this method public. We freaked out about this earlier when it was page aware variant plugins, but page aware variant entities does not bother me in the slightest.

8. +++ b/src/Entity/PageVariant.php
   @@ -316,6 +327,39 @@ public function removeSelectionCondition($condition_id) {
   +  public function setStaticContext($name, $configuration) {
   +    $this->static_context[$name] = $configuration;
   +    return $this;
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function removeStaticContext($name) {
   +    unset($this->static_context[$name]);
   +    return $this;
   +  }
   

   I think these might should reset $this->context to prevent a stale context array.

9. +++ b/src/EventSubscriber/CurrentUserContext.php
   @@ -65,7 +65,7 @@ public function onPageContext(PageManagerContextEvent $event) {
   +    $event->getPage()->addContext('current_user', $context);
   

   Answered my own question.

10. +++ b/src/PageVariantInterface.php
    @@ -100,4 +107,45 @@ public function removeSelectionCondition($condition_id);
    +  public function getStaticContexts();
    ...
    +  public function getStaticContext($name);
    ...
    +  public function setStaticContext($name, $configuration);
    ...
    +  public function removeStaticContext($name);
    

    Still not sure about the names on these methods. This doesn't tell me that it's definition level data, not actual data objects. I find that confusing.

1) That's the same perm we use for everything controller by that section of the UI: the page variant itself, the selection conditions, the blocks, and now the static contexts

2) Agreed.

5) Yes

6) I thought we did too, but it's just in \Drupal\Core\Config\Entity\ConfigEntityBase::preSave()

8) Good call! Working on that

10) I agree, but I'm not honestly sure about any of the names we brainstormed before. Also, these are moved from one interface from the other... Can we open a follow-up to rename these instead of holding this up?

Here are some more fixes, and more tests. Still need to fix #7.8

I think this is enough?

Pushed!