In some cases, we don't want to delete the whole dependency tree if one configuration entity is being removed.
The Drupal core example are view and form displays.
Assume that you have a module that provides a field (as default configuration, or by providing the field type plugin). That field is added to node articles, together with 15 other fields. The view and form display modes are configured to display that field with a specific formatter/widget.
Right now, if you uninstall that module, it will forcefully remove all your display configurations that contain that field. But that's not what you want, you still want to display all the other fields with their configuration.
Another example is the Search API module, which is ported to 8.x here: https://drupal.org/sandbox/daeron/2091893
It has search servers/backends, for example database or solr. Then you have search indexes which use a specific server, have data sources with fields (can be configurable fields and then need to depend on them) and processors, which are plugins, so we need to depend on all those things to make sure that it's installed/synced in the right order. This is happening here: https://drupal.org/node/2257081.
But if you remove the module that provides the server, we want to update the index to disable itself and remove the dependency on the server, and if you remove a plugin, we want to remove just that, and not delete the whole index, and views that depend on it and so on.
ConfigEntityInterface::onDependencyRemoval() to allow configuration entities to respond if their any of dependencies is going to be removed (ie. if an entity is going to be deleted or a module uninstalled). This method allows configuration entities to remove dependencies instead of being deleted themselves. When a module is being uninstalled configuration entities can use this method to avoid being unnecessarily deleted. Implementations should save the entity if dependencies have been successfully removed.
For example, entity displays remove references to widgets and formatters if the plugin that supplies them depends on a module that is being uninstalled.
User interface changes
The message about deleting configuration entities as a result of module uninstall is changed. As a result of this patch we don't know if they will be deleted or just updated so we list affected entities.
Original discussion of a resolution
Discussed with @alexpott, what we should do is introduce an API that lets us ask a config entity if can continue to exist without that dependency and heal itself. If so, we let it do it, otherwise we delete it.
Deletion happens top down, if you have a search server, a search index that depends on that server and a view against that index, we first need to ask the index what we should do if the server is removed, and let it self-heal, otherwise we'd delete the view because the view can not self-heal itself from the index being removed before we'd learn that we don't have to delete the index.
Not sure if we need two separate methods to check if it can remove the dependency or if we just have on that does it and returns TRUE or FALSE?
We will probably also at least update the uninstall page to explain that not all config would be deleted? But it would be better if we'd already know then what will be deleted and what not, would be very confusing/fragile/scary to silently rely on this. But then we certainly need two methods...
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 76,281 pass(es). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 2260457.34.patch. Unable to apply patch. See the log in the details link for more information. View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 76,121 pass(es). View