Fix config schema

Changing the title to reflect the larger scope. Missing are, as far as I can see:

• The normal settings (present in the proper module already – though with other settings, back then)
• Index options: "fields", "additional fields", "processors"
• Also, I think we'll need definitions for the configurations for each of our datasource, tracker and processor implementations, right? That's what the search_api.datasource.plugin.[%parent.datasourcePluginId] magic does, unless I'm mistaken.

Also, though that's maybe a different issue, the properties are rather inconsistent. machine_name vs. serverMachineName, for example, and datasourcePluginId is just a bit verbose. Same for the option names: cron_limit vs. additional fields.

About "machine_name vs. serverMachineName", core tries to follow the snake case pattern for this (but doesn't always succeed :P), we should try to match that as well.

And "additional fields" is definitely wrong, it should have an underscore there.

I'm wondering if this issue should wait for any other architectural changes, like #2230931: Supporting multiple item types per index. By the way, are there any other big ones besides that?

#2241429: Support translations might also be a larger change, but should ideally only affect the content entity datasource.

Other than that, #2044421: [meta] Upgrade to Drupal 8 lists all the current goals for the module. I don't think there are any larger architectural changes there, but until RC status, anything could still come up.

In any case, I think we can just do this at any point at which we want to, and just (try to) remember afterwards to also update the config schema when making any related changes.

Committed a small patch for search_api.settings.yml: http://drupalcode.org/sandbox/daeron/2091893.git/commitdiff/60dbcd2

I think the rest should be postponed on #2230931: Supporting multiple item types per index so we don't cause unnecessary conflicts.

Agreed. Thanks!

Hm, I think this can be un-postponed now?
Does anyone want to work on this? Or should we still wait, until we are moving back to the original repository?

Thanks a lot!

Sorry, I was busy with other work before so couldn't respond in IRC:

and last but not least, views groups the ID listing and the config under one single key
in search_api ypu have 2 arrays now
one with only the ID's and one with the config
I think (if possible) we should merge it into datasourcePlugins

It was like that before, and I would like it much better, too, but someone said for the config schema having it in two separate properties makes more sense. If this is not the case, all the better!
In general, do what you must to make this work, the current storage schema isn't set in stone. I'd also be far from against overriding toArray() – at least we could then finally declare $original as a property and get rid of a few code style warnings. ;)

From short dicussion with Nick: search_api.processor.plugin.node_status seems to lack a mapping for its settings.

This patch should fix all the issues that I see with the current schemas. Note that the "datasources + datasources_configs" problem is not finished yet but pending on the resolution of #2291073: Config schema doesn't support referencing plugin derivatives in core.

Fixed a wrong indentation, noticed by @aspilicious in IRC.

I'm pretty sure removing the schema for plugins that don't have any configuration is perfectly ok.