Reorganize and simplify module names

[dafeder]

For reasons that are difficult to remember today, we made a decision early in DKAN 2 development to make our module machine names extremely simple -- "metastore," "datastore," etc, without prefixing them all with “dkan_.” We came to regret this fairly quickly. We also have some confusing division of central DKAN functionality between “DKAN,” “common” and “metastore.”

Given what has coalesced as the core functionality in DKAN, we should in version 3 take the opportunity to optimize our naming conventions and separations of concerns. Current recommendation is:

DKAN (dkan)

This will for the most part consolidate all code and functionality spread across “dkan,” “common,” and “metastore.” Because there is no DKAN without the metastore, and all additional modules interact with the metastore in one way or another but not necessarily with each other, it makes more sense to consider all of this part of the main dkan module.

The overall Metastore system -- the majority of the code in modules/metastore/src -- will now be considered the core functionality of DKAN. So, Drupal\metastore would become the Drupal\dkan namespace. Our service and route names could, for the most part, remain unchanged. The search module would now be dkan_search.

The DKAN module should not depend on any additional submodules; we would still have a working data catalog with API if the dkan module is enabled and nothing else is. We would perhaps add another parallel functional test job to the CI that tests the system without datastore, harvest or other additional modules enabled to make sure it works.

There is a class currently in common -- DatasetInfo -- that breaks a lot of separation, because it relies on all the other modules to bring together the dataset info from around the system. This will need to implement a plugin system to allow other modules to add information if enabled.

DKAN Datastore (dkan_datastore)

The Drupal\datastore namespace would now be Drupal\dkan_datastore. Little here would change, we would simply create more isolation so that it could be disabled.

DKAN Harvest (dkan_harvest)

This would follow the same pattern as dkan_datastore, mostly remaining the same but possibly with some refactoring of certain functionality to allow the core DKAN Metastore to be enabled without it. We may want to let the Harvest module contribute information to DatastoreInfo.

[paul-m]

Deemed out of scope from #4260

Copied here so we don't lose it:

DKAN 3.x:

• renaming modules?
  • common and metastore move to dkan root
  • investigate how the project name works
• need an upgrade path/instructions to 3.x
• plan support for 2.x