Enable config flow for html5

[alexyao2015]

Breaking change

Proposed change

This converts HTML5 to use config flow. In the process, this also removes the need for the user to manually obtain a VAPID key as it is now automatically generated.

This also removes the long deprecated GCM configuration method.

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: Config flow documentation for html5 home-assistant.io#31805

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
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format 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.

To help with the load of incoming pull requests:

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

[sdb9696]

This looks really good to me. I've looked at a number of other integrations using config flow with the notify platform (i.e. google_mail) and the approach seems consistent.

The notifications are consistent with the following architecture policy: https://github.com/home-assistant/architecture/blob/master/adr/0021-YAML-integration-configuration-deprecation-policy.md

The removal of the gcm_api_deprecated makes sense to be included in this PR as it's part of the old config and shouldn't be carried over to the config flow.

The tests look good with 100% coverage.

A few suggestions and one question about the parameters passed to async_load_platform below. Also I'm not sure it makes sense to make the service async for the reason below.

[sdb9696]

One item left which is to revert the get_service back to a sync function unless I'm somehow missing why it was necessary.

[alexyao2015]

The get_service call just got converted to an async function. #116068

[bdraco]

Its not thread-safe to call hass.http.register_view or hass.services.async_register in the executor. It should have been an an async function all along

[sdb9696]

Its not thread-safe to call hass.http.register_view or hass.services.async_register in the executor. It should have been an an async function all along

Ah ok, my bad I didn't know that, thanks @bdraco. This is all good from me, thanks @alexyao2015!

[sdb9696]

LGTM!

[bdraco]

Suggested change

	if entry[CONF_PLATFORM] == DOMAIN:
	if entry[CONF_PLATFORM] != DOMAIN:
	continue

Than outdent below

[bdraco]

testing....

[bdraco]

dismiss service is there

[bdraco]

notify.html5 service is missing though

[alexyao2015]

Issue is fixed

[bdraco]

I did some testing. Some observations:

• After enabling the notifications, I still have to restart for the new service to appear
• Sending a notification via the new service after restart didn't work in firefox or chrome

[alexyao2015]

I retested this again.

• Having to restart appears to be the status quo. Services are loaded in using the legacy notify platform which controls the need for a restart. This aspect was not changed.
• Sending notifications after restarting works from notify.html5, notify.notify, and notify.html5_mydevice. The service worker must be activated for notifications to function.

[bdraco]

It seems like it defeats the purpose of converting to a config flow if you have to restart for the service to exist. We could use the discovery helper to discover the new service immediately.

[alexyao2015]

defeats the purpose of converting to a config flow

This mainly helps with setup so users don't have to manually obtain vapid keys since they are now automatically generated.

the discovery helper to discover the new service immediately

Do you have an example of how to do that?