Add "name" property to HostingService classes to allow for human readable service selection

Seems like a great idea, but does it require updating the hook_hosting_services() implementations? eg this.

I'm guessing we don't need to, but just making sure.

Yeah, figures. I don't see a problem with this patch but I'd like others to comment if possible since it's a complicated area of the code.

I get a number of these warnings after merging this branch....

Warning: Missing argument 1 for hostingService::__construct(), called in /var/aegir/hostmaster-2016-04-19_13-56/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.module on line 406 and defined in __construct() (line 15 of /var/aegir/hostmaster-2016-04-19_13-56/profiles/hostmaster/modules/aegir/hosting/server/hosting_server.service.inc).

The constructor currently likes to get a $node parameter ....

+1 otherwise though

    foreach ($service['types'] as $type => $class_name) {
      $serviceClass = new $class_name;
      $options[$type] = isset($serviceClass->name)? $serviceClass->name: $type;
    }

Why are we instantiating the classes again? If the node exists, $node->services ought to contain service objects. Otherwise, they're already being instantiated a little further down in hosting_services_new_object().

Could we default $serviceClass->name to $type in hostingService::__construct? Or perhaps add a getter function for that (e.g., hostingService::getName())? That way, it'd consistently be set within the object, rather than having to redo that check wherever we might want to display it.

Should we perhaps differentiate between the $name we get back from hosting_server_services() and $serviceClass->name? That is, consistently call (at least one of) them $machine_name and/or $serviceClass->humanName, respectively.

Finally, I think we'd also want to use these human names as the column header is our servers view, no?

Sorry but the 2714561-hostingService-name branch gives a merge conflict.

Thanks, Looks much nicer on /hosting/servers