Identify content vs. configuration

This looks good, committed to 8.x

I'm not sure if it's correct to re-open this or to open an new issue, but I think that the list here needs to be updated so it's reconciled with MigrateDrupal6Test

I made a spreadsheet that highlights the discrepancies between the two:
https://docs.google.com/a/happypunch.com/spreadsheets/d/1AwJ5NTvlsEsDpaI...

I've moved these files into the root of the module in d0fa9a5 to fix DefaultConfigTest

Once #2200379: Upgrade UI is committed to the sandbox, I'd like to return to tagging the migrations with a 'type' option. The hardcoded manifests were helpful to get this bootstrapped, but we'll still need to do this so contrib modules can add their migrations to the upgrade process.

All right, I've rerolled bdone's patch with the config directory move, and the UI now uses the configured destination type rather than explicit manifests to determine what to import. With this patch, D8 contrib modules can simply package migration configurations for their own content and configuration, and by specifying the type have them automatically incorporated into the upgrade process in the right spot.

$migrations = $this->storage()->loadMultiple(); this will load everything D6, D7 and even D8->D8 when that gets written. That's not optimal. The battle plan was that based on the presence of the system table and the schema version of system module therein we detect whether the source is D6 or D7 or D8 and load the content/configuration manifest accordingly. If contrib is a concern (it is) then an alter hook is in order IMO.

Can we split this up and add the type: keys to the migrations in the core queue since the D6 migrations have all been committed to core.

So, there was some discussion on this in IRC a few weeks ago, and as I recall chx was on board with adding both the type: key (for identifying configuration vs. content) and a version: (or drupal_version:?) key with values like 6 or 7. This I think is optimum DX for contrib authors supporting migration of their module's data, simply adding a couple lines to their configuration file(s) so they are processed in the right context. If that sounds OK, then I think this issue, with a patch to add the keys to the D6 configuration files, should move to the core issue queue, with a new issue in the Migrate Upgrade queue for the UI to use this information.

That all being said, where should the keys go? Initially I just added type: to the top level of the YML. I'm wondering, though, if the type should be part of the destination configuration, since it represents what kind of Drupal data we're creating (well, more-or-less, because blocks are weird). And if so, why not bake that into the destination plugins themselves? One less key in the YML...

As for the source Drupal version, this makes sense to me as a drupal_version key under source. So:

id: d6_action_settings
label: Drupal 6 action configuration
source:
  plugin: variable
  drupal_version: 6
  variables:
    - actions_max_stack
process:
  recursion_limit: actions_max_stack
destination:
  plugin: config
  type: configuration    # Or omit here if we build this into the 'config' plugin definition
  config_name: action.settings

Now, looking at that, I'm thinking maybe a top-level key named 'source_version'? Thoughts?

Let's close this as it's had it's day