Update service domain for local_file from 'camera' to 'local_file'

[raman325]

Breaking Change:

This change breaks existing service call references to the camera.local_file_update_file_path by changing the service call to local_file.update_file_path. My understanding is that because this is not a service provided by the base camera component, it should live in the domain of the local_file component instead. If that's the case, then it also makes sense to update the service name.

Description:

Update the domain and service name for camera.local_file_update_file_path. I started down this path because of #27289 and based on the introduction here and comment here, I felt this change made sense. If I am misunderstanding the intent please let me know so that I don't keep moving through these changes, as I have noticed this pattern emerging across a bunch of integrations as I commented here. Unfortunately I don't have a device to test most of these integrations.

Related issue (if applicable): Related to #27289

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

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.
• I have followed the development checklist

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

• Documentation added/updated in home-assistant.io

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

• The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

If the code does not interact with devices:

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

[dshokouhi]

Check the services section in the UI and see if the drop down of entities still filters by the camera. Changing the domain may get rid of this user friendly option.

[raman325]

@dshokouhi did not think about that. The end result is that there is no filter applied to the list:

While I agree that the camera entity filtered list is better than the unfiltered list I get when I change the domain of the service, it can still lead to bad service calls since it is not guaranteed that all camera entities are using the local_file platform. I feel like directionally moving this service to the local_file domain would lead to a better approach because the entity discovery feature could be updated to filter entities where entity platform = service domain. Where I see this being a potential challenge is when an integration supports multiple device types. In order for the entity discovery feature to work properly, it implies that an optional device_type property should exist for service definitions in services.yaml, which could then be used to find the right device_type specific entity for entity discovery.

Thoughts? I realize this is well out of scope of the PR, and I am open to closing this PR and opening a new discussion in the architecture repo or somewhere else more appropriate.

[balloob]

This service should be moved. Flaws in the UI should not guide our backend decisions 👍

[balloob]

One minor comment, ok to merge after this!