Make Aegir aware of site-specific packages

Not sure if I understand the intention here, but site specific packages have been excluded by design - because then you will easily break ability to upgrade. It is a discouraged practice to use site specific space for any code, because it creates an unavoidable chicken/egg syndrome on upgrade, which essentially depends on differences between codebases (platforms). When you are using site specific code space you are making upgrades impossible, because there are no different codebases to compare and check for upgrades/compatibility etc. See also: http://community.aegirproject.org/node/243

It is an old, known issue discussed many times, and the reason why we have added an auto-run Verify task to Migrate task in BOA. There is a built-in verify, but it doesn't work -- you need to run verify via frontend to make it work.

But in the principle, I would vote against encouraging people to use site specific space for code, since it is against Aegir core concepts.

See for reference: #1004526: Automatic aliases are not persisted across rename and clone

I didn't have time to properly test this yet, but committed one bugfix to the dev/packages-count branch.

I don't like the idea of *requiring* a verify before we migrate sites.

The reason why those modules were ignored is exactly that: we didn't want to have to run verify on all sites (which includes clearing cache and all sorts of performance impacts) before migrating.

However, this was necessary, I believe, because we were considering site-specific packages in the site platform comparisons.

Now on with a code review:

+    watchdog('[HOSTING PACKAGE]', 'Unrecognized entity type (' . $type . ') passed to hosting_package_instance_sync().', array(), WATCHDOG_WARNING);

watchdog documentation says the first argument is "The category to which this message belongs. Can be any string, but the general practice is to use the name of the module calling watchdog()."

So '[HOSTING PACKAGE]' should be hosting_package.

Also, there's a todo here:

+  //TODO: Rebuild the 'hosting_package_instance' table. That is, drop it, and then trigger 'verify' tasks on all platforms and sites.

why is that: does the patch work without those verify? why do we need to clean that table? See also #1034520: Cleanup zombie entries in hosting_package_* tables?.

Finally, I feel it is a bit late in the release cycle to try to introduce such a change. If you are confident it works, go ahead, but I really don't want to start messing around with failing migrate paths in the frontend in 2.x again. Remember that this is your last chance to change the API (so the database structure!) - if we mess it up in the 2.0 release, it's hard to go back if the DB is not sound...

But I will trust your judgement on this, you see that have gotten a good understanding of how this code works.

In fact, this is needs work - maybe just cosmetic in case of that watchdog() call, or an actual "needs implementation" for that todo.