Separate default implementations from services

This issue stemmed from some closing thoughts in #2004360: Clean up Hosting 'Features'.

To follow up on the idea of either/or dependencies, there are a number of issues in Drupal Core related to specifying further relationships between modules:

• #92233: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file
• #1234668: Similar Modules - alternatives[], replaces[] and replacedby[] field in modules .info file
• #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files

In the long run, alternatives[], enhances[] and suggests[] may be useful here. However, I don't think the module dependency system is up for this anyway.

Part of the problem is that allowing someone to enable (for example) SSL, without enabling an actual implementation (Nginx SSL or Apache SSL), could be confusing, as they wouldn't actually get any additional functionality from that feature alone. We could simply not have Hosting features for these base service implementations. Alternatively, we could introduce a new Hosting features status: HOSTING_FEATURE_API (or something like that). We could then block it from being enabled directly, or prompt users to enable one of its implementations.

But the real problem is that, if we want (for example) Apache to be able to be disabled, then it can't be HOSTING_FEATURE_REQUIRED, even if Web Server would be. This, in turn, makes it quite easy to break Aegir, since we could then end up without any available Web Server implementation.

Drupal module dependencies, even the proposed new ones, or an 'either/or' won't really help here, since the dependency would be reversed. That is, Apache (and Nginx, etc.) should logically depend on Web Server, and not the other way around. Furthermore, we'd want the relationship to be defined in the implementation, so as to allow other implementations (e.g.: lighttpd, etc.)

One way to do this would be to add one or more optional fields to the array returned by hook_hosting_feature(). These could specify that feature is defining or implementing an API/base-class. We could then check these when validating the Hosting features form.

Either way though, not a 6.x-2.x feature.

870c6a0a41905 makes it possible for a module to only define a service type, without having to define an actual service.

An example of separating the service type from its implementation can be seen here: https://gitlab.com/aegir/hosting_certificate

As for the concerns above about ending up with a service type enabled, but no implementations of the service, we can do a couple things. We could implement hook_modules_disabled() in the web and db service types that enforces at least one service implementation being enabled. Better might be to hook_system_info_alter(), and implement our "one_of" type dependency.

If we're really serious about avoiding the "shoot yourself in the foot" scenarios, we should probably also look at ensuring that the web and db servers on which the @hostmaster site is installed have an http and db service enabled, respectively.

Likewise, we can document that the service type features don't provide any functionality on their own; both in feature descriptions and in post-enable hooks.

Currently the server form throws errors when a service type is enabled, but no implementations are:

Notice: Undefined index: types in hosting_server_form() (line 406 of /var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module).
Warning: array_keys() expects parameter 1 to be array, null given in hosting_server_form() (line 406 of /var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module).
Notice: Undefined index: types in hosting_server_form() (line 411 of /var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module).
Warning: Invalid argument supplied for foreach() in hosting_server_form() (line 411 of /var/aegir/hostmaster-7.x-3.x/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module).

We'd need something like a "provides" dependency. Composer handles this nicely. But for now, we could just throw a warning in hosting_server_services() if there are no implementations of a service type.

The issue noted above is resolved by throwing a warning on a servers page, as in f32a34b3