Add config for trusted networks auth provider

[awarecan]

Description:

Add config for trusted networks auth provider.

Breaking changes
It is a breaking changes for user who manual configured trusted network auth provider. An invalid config error will be thrown and HA won't be able to fully started.

It is NOT a breaking changes for user who didn't manual configured trusted network auth provider.

If trusted_networks configured in http component, and no auth_provider configured in core config, http.trusted_networks value will be used for default loaded trusted network auth provider.

Related issue (if applicable): fixes #16149

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#8605

Example entry for configuration.yaml (if applicable):

homeassistant:
  auth_providers:
   - type: trusted_networks
     trusted_networks:
      - 127.0.0.1
      - ::1
      - 192.168.0.0/24
      - fd00::/8

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.

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

• Documentation added/updated in home-assistant.io

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[elupus]

May I suggest a different syntax now that this is changed? May not be required, but id like to mention it.

It would be nice to be able to map a range to a user. Also allow X-Forwarded-User header from some ip:s to map to hass user.

So we'd need config options on each ip entry.

Simplest might be to just make it a dict instead of list.

[awarecan]

IP / user mapping could be done in separate pull request. I want to keep PR small.

I won't add X-Forwarded-User support, that should be done by another "trusted proxy" auth provider, not trusted networks auth provider

[elupus]

I understand that. But I just meant change config structure to dict instead of list.

[balloob]

@elupus I think it's fine. We can always add a new key user_trusted_networks.

[balloob]

The reason we had an or is because people can have a config like this:

http:

And then it can be None? Although if I remember correctly, we do replace None with {}…

[awarecan]

trusted_networks will be None for the case

http:

[elupus]

My idea was just to be able to do:

192.168.1.1/32:
    mapped_user: pete
192.168.1.2/32:
    mapped_user: dave
192.168.1.3/32:
    mapped_user_from_proxy: true

But sure it's no problem to handle this in a different format.

[awarecan]

@elupus that feature will change several places in the login flow, not only in the config of trusted networks auth provider. A separate pull request is need.

[balloob]

Let's drop this one.