Clarify duplicate host management in federated reporting docs

[larsewi]

Summary

• Reframe the "Duplicate host management" intro around the approach distinction (source-side vs destination-side) rather than treating distributed cleanup and handle-duplicate-hostkeys as if they addressed different lifecycle scenarios. Both mechanisms address the same underlying problem: the same hostkey appearing on multiple feeders.
• Distributed cleanup is now described as a source-side cleanup (deletes stale records from the feeders via API, before re-import).
• Handle duplicate hostkeys is described as a destination-side filter (moves older duplicates into a dup schema on the superhub during import).
• Added a caveat that neither mechanism deduplicates clones reporting to the same feeder, since the feeder's __hosts table is keyed on hostkey (verified against nova/db/schema.sql).
• Dropped "fail over" from the list of causes — there is no automatic failover for federated reporting agents, only operator-driven re-bootstrap.
• Updated the distributed_cleanup.py prompts in the bullet list and the example console session to match the current script: separate admin username/password prompts (defaulting to admin), and 2FA prompts when enabled.

Example output

# /opt/cfengine/federation/bin/distributed_cleanup.py
Enter admin username for superhub ip-172-31-12-171 [admin]: larsewi
Enter admin password for superhub ip-172-31-12-171: 
Enter email for fr_distributed_cleanup accounts: larsewi@doofus.com

Enter admin username for ip-172-31-6-8 [admin]: larsewi
Enter admin password for ip-172-31-6-8:

[craigcomstock]

Can they be enabled together? The destination-side would take only add the newest record into the superhub database, without the duplicate entries in the superhub the source-side process would have nothing to delete on the feeders. I don't think this comment is accurate.

[larsewi]

I don't see why not. But I guess it would not make any difference, so might as well remove it ;)