Refactor "command timeout" handling

[mStirner]

The timeout should apply to the time between when the data was sendet and the answer from the device. When no connector is available, the connection timeout should apply, but instead the "command timeout" fires before the end of the "connection timeout" (default 30s) was reached.

When the connection timeout > command timeout (which is the case) then the command timeout fires every time before the connection timeout.

Correct flow would be: on success

• trigger command
• opens connection
• send command payload
• waits for response
• timeout or receive response

on failure

• trigger command
• opens connection
• connections request timesout
• no "command timeout" is fired

NOTE: Keep in mind that changing this also affect the "Presets" handling in endpoints (#439)

[mStirner]

There are/should be 3 timeouts:

• connection timeout (bridge/connector)
• command timeout (general, command not send/no response)
• command response timeout (response from device)

"Connection timeout" should be relative high e.g. 30s. "Command timeout" should be higher than response timeout, e.g. 5s. "Command response timeout" should be lower than "command timeout", e.g. 2s

3s between sending the command, and receiving a response from a API/device should be more than enough for the most scenarios.

The 5s "command timeout" is there to log that the command request/payload was not even written to the device/API. (is this even needed?, when "connect timeout" exists.)