Freeze exception to refactor the client node type?

We have been pretty loose on the announced freeze so far and have merged a bunch of non-critical fixes in the release candidates. While this is against our policy, this is our first attempt at really stabilizing the code and I don't think it had ill effects. Now I need to do something that could have adverse consequences for production sites out there.

First, a bit of context: I have done a lot of work this week to get a better security model working for Aegir. This could allow for better intersite security (site A not being able to touch site B files) and, more importantly, allow regular users to run drush on their sites. The problem is that to integrate properly with external authentication (like LDAP or others), we need to cleanup the Client node type. This is an old issue (2009!) in aegir that I have been annoyed with for a long time.

The idea suggested in #962330 is that we refactor the client content type to have only two fields: the node title (the client name) and an internal name (mostly hidden from the user). This would involve dropping the Organisation, Email and Name fields from the content type. From there, a bunch of things follow: notification emails can be sent to the user operating the site instead of the client email, we fix the client duplication issue we currently have, and allow for much better interoperability with other CRMs (my target is LDAP integration).

So far, I have been able to implement a patchset (in the dev-refactor-client-962330 branch) that allows for a somehow smooth transition: the client title is taken from the organisation, the old client name or the email, taking the first available in that order. The internal name is "bruteforced" to be unique based on a silly algorithm of adding an integer after duplicates. We keep the email, name and organisation fields in the database for patching up after the upgrade, but note that the email, organisation and name fields will be dropped from the hosting_client table in the 2.x branch.

So while this transition could be destructive to some users (the node title is changed), I think it is really important to do it now while we're not that stable, at least officially. Waiting for 2.x for this change would mean a significant delay on my side and a much bigger impact, if we consider the adoption we will get once 1.x is really out there. I also think the current node data is mostly useless and unusable as it is, so it would only clean up things for us.

The big question is: is anybody really using those email and organisation fields out there?

Does anybody have an objection to me merging in those changes in the stable branch? They will certainly be merged in the master branch anyways (unless somebody suggests a better solution), so it's a bullet we'll all have to bite at some point, better do it now, I think.

Let's give this a week delay for testing and feedback, then I'll merge this in.