Make sure to handle uninstalled modules providing plugins correctly

Core has a very strict dependency system for config, and each config entity can depend on N modules and other config entities. This ensures that configuration is automatically removed when dependencies are removed (This is unfortunately very strict, the nice thing is that it shows you on the uninstall screen what it will remove).

The system will also ensure that configuration is installed/synced in the right order, which is currently a problem. So we should make the index depend on the server (right now indexes are installed before servers because it's alphabetical if there is no explicit dependency) and things like fields, plugin providers and so on. Entity form/view displays are relatively complex core examples (calculateDependencies() Figuring that out will not be trivial, as we'll need to ask the data source what dependencies we have through the enabled fields...

Me and @Berdir were just discussing this problem a few hours ago :) The index not depending on the server is fixed in #2257095: The database backend doesn't create columns when servers and indexes are created from default config because it was needed in order to fix the first bug there, and I'll work on the remaining problems.

Here's a patch which makes Index and Server return all their dependencies, including field and instance config entities coming from each datasource of an index.

I'll think about how to best handle #4 after lunch :)

Yay!

I can confirm that with the patch, I can add an index with server to the default config folder of a module/profile which already contains fields that the index depends on, which didn't work before.

I did notice a few things when testing, but they're not related to this issue I think, will open separate issues where it makes sense/when I can reproduce:

1. Looks like hook_cron() doesn't work yet, because things aren't indexed when I run cron?
2. Sometimes I get weird errors/exceptions because the server forgets about the index or something, then I had to edit, remove server, edit again, add server and then enable again, then it worked again.
3. Those edits and it not working initially resulted in my tables getting numeric suffixes, for example, I have now tables like search_api_db_{index}_1, and some field tables had up to _4 as a suffix, interestingly, despite that then being the default config after I re-installed, it went back to no suffix except the index table?

Re #4:

I don't think it deletes automatically right now except when you uninstall a module, then it explicitly looks at your configuration dependencies and tells you what it is going to remove. See screenshot (the configuration fieldset is hidden by default, though)

We can use that dependency API on the delete confirmation form to easily find the indexes that depend on us and then remove them from the server (as we do now, except the UI part?)

I don't think we can prevent this if modules are uninstalled that provide processors or fields, though. Will ask @alexpott to comment...

Removed manual creation of fields and instances from SearchApiDbTest in favor of default config files.

The problem described in #4 is not really about the delete confirmation form, but about that screenshot posted in #7, where we don't want to remove the index when a module that contains its server backeng is uninstalled. I'm not sure what to do there, we do need the dependency at install time, but we don't want it (somehow) at uninstall time.

I'll wait for some advice from @alexpott on how we can do that :)

I opened #2260457: Allow config entities to remove dependent configuration keys when dependencies are deleted due to module uninstall because core has similar problems with entity view/form displays, which shouldn't be deleted if you remove a single field.

I looked into solving the backend-providing-module uninstall problem and it's not possible without the core issue that @Berdir mentioned above.I'm going to commit this patch so we have proper dependencies declared now and mark this issue postponed to implement the self-healing process when we have it :)

Committed a small followup to use the new trait available from #2266859: Move the dependency calculation helper methods from ConfigEntityBase to generic traits.

http://drupalcode.org/sandbox/daeron/2091893.git/commit/3a44cdafedce6c88...

20 commit references later, the core issue finally made it in, so we can unpostpone this and implement the new method. See changes to EntityDisplayBase in #2260457: Allow config entities to remove dependent configuration keys when dependencies are deleted due to module uninstall as an example.