ZHA backup/restore config flow

[puddly]

Proposed change

Adds network formation options to ZHA's config flow. This lets you decide how to handle network information when setting up ZHA:

• Erase network settings and form a new network.
• Restore an automatic backup.
• Upload and restore a manual backup (frontend PR allows backup downloads).
• Continue with the existing settings on your stick.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[balloob]

Can you include some screenshots

[puddly]

Some screenshots:

[Hedda]

@puddly Will there be a warning that EUI64 can only be overridden once via ezsp on EFR32 and EM35x based SoCs? At least I understand changing (overridding) EUI64 token is a one time operation over EZSP so after that you will need to erase and flash manually via JLink if want to overwrite the EUI64 token more than once? So you can restore backup as many times as you want but you can override EUI64 only once, unless you use an SWD flasher like a JLink adapter?

If so then maybe add a warning like;

"Be careful when migrating/restoring a backup made from another adapter as some types Silicon Labs based Zigbee Coordinator controllers only accept a single restoration procedure of the EUI64 token via EZSP, so if need to override EUI64 once more then you need to erase and flash the firmware manually via a JLink SWD flashing adapter".

and make the user tick a checkbox to approve:

"I understand that I can only update EUI64 token only once and I still want to do it now"

https://www.reddit.com/r/homeassistant/comments/ixqbsw/backup_your_zhahusbzb1_stick_and_even_seamlessly/

"For seamless migration, you need to overwrite the EUI64 on your target stick/bridge. This is a one time operation and can not be undone or changed in future (without a SWD flasher) so this should only be done if you are sure of the change. If you do not overwrite the EUI64 the binding tables on your devices will be incorrect and they will need to be reset and rejoined. That said, there is very little downside to overwriting the EUI64 -- You can have two sticks/hubs with the same EUI64 online at the same time with out any conflicts if you create a new network on one of the two sticks. (bellows leave && bellows form)"

References:

zigpy/bellows#414

zigpy/bellows#458

zigpy/bellows#295

zigpy/bellows#469

https://community.silabs.com/s/article/can-i-change-the-eui64-used-by-a-silabs-wireless-mesh-radio-x?language=en_US

https://www.silabs.com/documents/public/application-notes/an961-custom-nodes-efr32.pdf

[puddly]

Currently waiting on #77394 and #77417.

With the above PRs (and home-assistant/frontend#13506), everything works:

• I'm able to form a ZHA network with a Conbee, unplug it, and re-configure/migrate ZHA to a ZZH! without ever shutting down Home Assistant or losing entity customizations.
• Similarly, Allow ZHA startup to fail instead of raising ConfigEntryNotReady #77417 allows ZHA to be reconfigured from a completely failed startup state (i.e. unplug the coordinator and restart Home Assistant).

Once I add a few unit tests for the options flow, this should be ready to go. Done.