Fix modbus blocking threads

[janiversen]

Breaking change

Proposed change

Since long before 2021.3 (as many think is working perfectly) the modbus integration have had a problem that caused threads to be blocked when a modbus device had problems. Pymodbus 2.30 was very "relaxed" and ignored quite a lot, so the problem was mostly ignored. I heard about it a couple of times, which caused a try to run pymodbus async. last year, with little success due to big flaws in pymodbus 2.30.

Pymodbus 2.5.1 (introduced in 2021.5) detected a lot more, and thus HA experienced that a lot more threads got blocked. A big thanks to @MartinHjelmare for pointing at the threading Lock() as a potential problem.

This PR changes the whole modbus integration to be async, however pymodbus is still used synchronously and thus there a switch from async to sync.

There is added a new test "test_thread_lock", that proves the problem:

• with threading Lock() 3 sensors and firing time events 5 times hangs.
• with Asyncio Lock() 200 sensors and firing time events 10 times works as expected.

This PR do not stand alone, if there are modbus communication problems they should be identified and solved,
to make that possible 2 new configuration variables are available:

modbus:
    ...
    delay: <seconds, default 0>
    timeout: <seconds, default 10>
    close_comm_on_error: <true/false, default true>

"delay" is used solely to postpone sending requests after connect.
"timeout" asks pymodbus to wait for a response, if a response comes earlier waiting is stopped
"close_comm_on_error" ask pymodbus to keep connections open even in case of errors.

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)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

Please add this PR (after review) to 2021.6

• This PR fixes or closes issue: fixes #
  fixes Something is blocking Home Assistant from wrapping up the start up phase #48894
  fixes Something is blocking Home Assistant from wrapping up the start up phase #49159
  fixes Modbus error with 2021.5.0 #50139
  fixes Something is blocking Home Assistant from wrapping up the start up #50155
  fixes Modbus sends first request too soon for slow devices. #50011

• This PR is related to issue:

• Link to documentation pull request:
  There are no new documentation.

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.
• 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 @adamchengtkc, @vzahradnik, mind taking a look at this pull request as its been labeled with an integration (modbus) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[janiversen]

I really like the expression GitHub uses "degraded performance for GitHub Actions." see:
https://www.githubstatus.com

In future PR´s I will use "degraded performance" instead of problems or bugs.

In other words, I will try again later.

[MartinHjelmare]

We also may want to set the PARALLEL_UPDATES constant to 1 in the platforms. This will make sure we don't try to run the service calls in parallel for entities within a platform.

https://developers.home-assistant.io/docs/integration_fetching_data/#request-parallelism

If a user would set up many different hubs with many entities for a platform, trying to run service calls in parallel would consume many thread pool threads.

[terminet85]

That's fix my issue #50610

[HarrisonPace]

Tested this PR, works as expected for both Serial Modbus RTU and TCP Modbus over IP. Maybe a Placebo but it feels like the GUI is more responsive, awesome work @janiversen adding asynchrony to this component.

[janiversen]

Added PARALLEL_UPDATES = 1, that should be the last of the requested changes.

[MartinHjelmare]

Great!