Editor settings altering not needed (and not compatible with config schema assumptions)

I am fine with that. I don't have enough info on what editors should support to complain about that :D In that case though, we should (a) postpone this on #2387141: Missing field configuration schemas across core tests and (b) build in settings filtering to not allow additional settings. The same was done in field settings, formatters, etc. For example this is in FormatterPluginManager

    // Filter out unknown settings, and fill in defaults for missing settings.
    $default_settings = $this->getDefaultSettings($configuration['type']);
    $configuration['settings'] = array_intersect_key($configuration['settings'], $default_settings) + $default_settings;

We also need tests that additional settings cannot be added. Also demoting to normal then and removing the D8 upgrade path tag.

So what is the point of editor_default_settings then? If we are to filter down settings to the keys allowed by getDefaultSettings() only (like we do with fields, widgets, etc) then hook_editor_default_settings() would not have the chance to add any new keys (or change values, since we only use it as additive). So there is no point in that hook then? There is only the point of the alter hook then to modify defaults.

From \Drupal\editor\Entity\Editor::__construct().

    $default_settings = $plugin->getDefaultSettings();
    $default_settings += \Drupal::moduleHandler()->invokeAll('editor_default_settings', array($this->editor));
    \Drupal::moduleHandler()->alter('editor_default_settings', $default_settings, $this->editor);

I don't think we have had the config entity system in its complete form back then...

OTOH this is the API docs for the defaults hook:

 * Modules that extend the list of settings for a particular text editor library
 * should specify defaults for those settings using this hook. These settings
 * will be used for any new editors, as well as merged into any existing editor
 * configuration that has not yet been provided with a specific value for a
 * setting (as may happen when a module providing a new setting is enabled after
 * the text editor has been configured).
 *
 * Note that only the top-level of this array is merged into the defaults. If
 * multiple modules provide nested settings with the same top-level key, only
 * the first will be used. Modules should avoid deep nesting of settings to
 * avoid defaults being undefined.

So looks like the assumption is modules extending editors with new features that would store settings on the editor object. Is there some documented use case for this?

So where are those plugins supposed to store their settings? Looking at editor.editor.*, its settings key is dependent on the editor type and nothing else.

Ok, so I guess we can assume that contrib modules should be able to extend editors that DO support plugins which is not baked into the default editor schema but it needs to be editor specific anyway. I am fine with that.

We also need to remove this hunk in this patch:

 class QuickEditIntegrationTest extends QuickEditTestBase {
 
   /**
+   * Set to TRUE to strict check all configuration saved.
+   *
+   * @see \Drupal\Core\Config\Testing\ConfigSchemaChecker
+   *
+   * @todo Altering not schema compatible. https://www.drupal.org/node/2389697
+   *
+   * @var bool
+   */
+  protected $strictConfigSchema = FALSE;
+
+  /**
    * {@inheritdoc}
    */
   public static $modules = array('editor', 'editor_test');

Was added in #2387141: Missing field configuration schemas across core tests to work around the fail.

The unit test will not need the module handler I believe. The Editor is not dependent on that anymore.

Nice, so you think my part looks good, I think yours does :)