support local socket connexions for mysql

This is a major wtf for new users. Our install script doesn't support local mysql connexions: it always goes through the network through the magic name resolution thingy. While it's good for multi-server setups (but we don't even support that in the installer) it makes things utterly painful during the original install.

here's a typical install run:

aegir@angela:~$ sh install.sh aegir.angela.anarcat.ath.cx --client_email=anarcat@anarcat.ath.cx
==> Aegir 0.4-alpha14 automated install script
==> MySQL is listening on 127.0.0.2.
==> This script makes the following assumptions:
 * you have read INSTALL.txt and prepared the platform accordingly
 * you are executing this script as your "aegir" user
Do you want to proceed with the install? [Y/n]
==> Aegir will now generate a mysql super user password for you:
  Username : aegir_root
  Password : 5dd9154acd53f435ebbf9ca0fe32353e
  Hostname : angela (127.0.0.2)

You will be asked to enter your mysql root user password now :
Enter password:
/usr/bin/drush
==> Drush is in the path, good
[...]
==> Installing the frontend
Project drush_make (6.x-2.0-beta9) downloaded to /var/aegir/.drush/drush_make.                                                                                [success]
The external command could not be executed due to an application error.                                                                                       [error]
Provision configuration path /var/aegir/config/server_master does not exist.                                                                                  [warning]
Backup path /var/aegir/backups does not exist.                                                                                                                [warning]
Provision PHP configuration path /var/aegir/config/includes does not exist.                                                                                   [warning]
SQLSTATE[HY000] [2003] Can't connect to MySQL server on 'angela' (111)                                                                                        [error]
Drush command could not be completed.                                                                                                                         [error]
Output from failed command :                                                                                                                                  [error]

Fatal error: Call to a member function quote() on a non-object in /var/aegir/.drush/provision/db/db.drush.inc on line 315

An error occurred at function : drush_provision_hostmaster_install                                                                                            [error]

Disregarding the cryptic error message that yields, we notice that we can't actually connect to that mysql server, even though the mysql server is up and runnin, and that hostname resolves (it resolves to 127.0.0.2, a common configuration for debian and ubuntu).

The workaround, here, is to change /etc/hosts from this:

127.0.0.1 localhost
127.0.0.2 angela.anarcat.ath.cx angela aegir.angela.anarcat.ath.cx aegir

to this:

127.0.0.1 localhost angela.anarcat.ath.cx angela aegir.angela.anarcat.ath.cx aegir

I think we shouldn't require such a change.

Furthermore, people that have "skip-networking" in their mysql configuration (also a common security measure taken by sysadmins) will notice it's simply impossible to install aegir at all, even if we use "localhost" as a hostname.

My take on this is that we should try to have better heuristics to guess the location of the mysql server. "localhost" should not be resolved and use sockets. If a hostname resolves to something within 127.0.0.1/8, we should also try "localhost" for the mysql server.

We can prompt the user for more info, and we can also take --db_server as an argument, which would incidentally allow for remote db servers installs.

Let's keep in mind that *all* UNIX hosts are at least dual-hosted: they have a network card of some sort and a loopback interface. Sometimes also a dedicated interface for a private lan. It is *very* common to have private services (mysql, nfs, etc) hosted on that private interface (lo or eth1) and we should support such a scenario. This may mean reorganizing the ip_addresses listing, but it will also solve major problems that are sure to happen with conflicts between mysql (which require a private IP), apache_ssl and DNS (which require a public one).

Maybe we want to have two sets of IPs? Or one set per interface?