Handle a config entity with the same name but different UUID being imported

This, from ConfigEntityBase::preSave()

    if (!$this->isNew()) {
      $original = $storage_controller->loadUnchanged($this->id());
      // Ensure that the UUID cannot be changed for an existing entity.
      if ($original && ($original->uuid() != $this->uuid())) {
        throw new ConfigDuplicateUUIDException(String::format('Attempt to save a configuration entity %id with UUID %uuid when this entity already exists with UUID %original_uuid', array('%id' => $this->id(), '%uuid' => $this->uuid(), '%original_uuid' => $original->uuid())));
      }
    }

That made some amount of sense to me. Now we want to blow away the original entity with something potentially completely different?

All other beta blockers are critical.

I don't fully understand this one yet.

This blocked on #2124535: Prevent secondary configuration creates and deletes from breaking the ConfigImporter as the test it adds nicely illustrates the problem we have. Once all the field instances are deleted the field system helpfully deletes the fields :) the config importer then tries to delete the field - which no longer exists.

Fixed FieldInstanceConfig to not do secondary deletes if a config sync is taking place and improved the test.

1. +++ b/core/lib/Drupal/Core/Config/StorageComparer.php
   @@ -170,11 +170,27 @@ protected function addChangelistCreate() {
   +          // not match. This means that the the entity has been recreated so
   

   'the the'

2. +++ b/core/modules/field/field.module
   @@ -223,6 +223,15 @@ function field_entity_bundle_rename($entity_type, $bundle_old, $bundle_new) {
   +  $view_displays = entity_load_multiple_by_properties('entity_view_display', array('targetEntityType' => $entity_type, 'bundle' => $bundle));
   +  foreach ($view_displays as $view_display) {
   +    $view_display->delete();
   +  }
   +  $form_displays = entity_load_multiple_by_properties('entity_form_display', array('targetEntityType' => $entity_type, 'bundle' => $bundle));
   +  foreach ($form_displays as $form_display) {
   +    $form_display->delete();
   +  }
   

   entity_entity_bundle_delete() does this too ...

Interestingly the order modules are enabled in DUBT tests matters! Changing the order to match how it would be in a real drupal install means the entity_entity_bundle_rename is fired before field_entity_bundle_rename and everything works as expected. Going to raise a follow up issue about DUBT module ordering and NodeType::postDelete removing field instances and entity displays. This needs to be done in preDelete since a field instance should never exist for a bundle that does not exist.

Missed point 1. from @swentel's review

The fail in Drupal\image\Tests\ImageStylesPathAndUrlTest is unrelated.

10: 2224873.10.patch queued for re-testing.

The test fails were unrelated to the patch - putting back to rtbc as per #10

Committed/pushed to 8.x, thanks!