When client detects it's a clone, mangled computer_title is used in all following registration requests

We are unsure if this is something worth fixing, but we should record what happened.

This started with a customer support case (https://canonical.my.salesforce.com/500D000001WTV77) where the customer was seeing a lot of computers with the title mangled with "(clone)" or "(clone of X)", but there were no clones. For example, computer "X" in the latter example doesn't exist.

Once upon a time, with an old LDS server, the customer indeed had valid clones. What caused them is a matter of archaeology now. The problem is that the customer installed a new LDS server, and the clones kept reappearing, but this time they were false.

The root of the confusion is that in order to point the existing clients to the new server, the customer didn't change client.conf nor ran landscape-config --silent to request a new registration. That would have restarted the client and this issue wouldn't have showed up. He simply changed the DNS record of the landscape hostname to point to the new LDS server (which is fine and elegant). Existing clients, when contacting this new server, realised they were not registered and simply requested a new registration automatically.

And here is the kicker: they did so with the computer_title value they had in memory. For the clones, that was "$computer_title (clone)", even though there were no clones now.

The workaround we gave to the customer was basically to restart the client, remove the computer from landscape, and let auto-registration kick in on its own. This time, because of the restart, the computer_title used was the one specified in /etc/landscape/client.conf.

The customer ended up running landscape-config --silent on the affected computers, but the end result is the same.

This scenario can be easily reproduced with just one landscape server and two clients, but in that case I think it's probably correct to keep the "(clone)" suffix. We might want to drop this suffix when registering with a new LDS server, and this can be detected with the server UUID change.

All in all, this may be too much of a corner case to be able to sort our correctly.