[boschindego] Provide faster channel updates

[jlaur]

This pull request implements a balanced way of using the API in order to provide faster updates and reduced load when fast updates are not needed. In addition, position tracking is now automatically requested when mower is active. This allows for updating the map with a frequency as high as six seconds between refreshes.

Some details:

• The most expensive call, /operatingData (contacting the robot), was previously called every three minutes (with default configuration). This has now been changed to every six hours when idle and every two minutes when active or charging. For a mower running one hour every day and charging 30 minutes, this reduces the number of calls per day from 480 to 49 while at the same time providing faster updates. It also fixes an issue with the display being always on, since this call wakes up the device.
• The most common call, /state, was previously called every three minutes (with default configuration). This has now been changed to every three minutes when idle, every two minutes when charging and every 30 seconds when active (in which case the result now includes updated map positions). For the same mower example, this increases the number of calls from 480 to 585 if the map channel is linked.
• The last/next cutting times are still updated once per hour, but additional updates have been reduced and at the same time been made more accurate. For example, the last cutting time will now be updated before the mower even returns to the dock.
• State update after triggering commands has been fixed to wait for new state and then start receiving updates with a frequency according to the need. Previously state would be refreshed before actually changed, so when starting a mowing session it could take up to three minutes to update state accordingly.

Related to:

• [boschindego] Optimization of API calls #13182
• [boschindego] Add operating data #12938
• [boschindego] Last/next cutting time #12986
• [boschindego] Add support for getting map #13017

[jlaur]

This PR is mostly an enhancement with faster updates and especially almost real-time map position tracking.

However, the first mentioned point about operating data requests can be considered a fix for a regression in #12938. At that time I was not aware that this request would wake up the device, effectively keeping it awake all the time (poll frequency three minutes, time for going to sleep 10 minutes).

Therefore it would be very nice to get ready in time for the first 3.4 milestone release to avoid potentially a lot of robots being contacted through the service way too many times. Potentially Bosch could take counter-measures and we could get into the same situation as the Gardena binding with HTTP error 429 ("Too Many Requests"). While working on this PR I have only experienced that a single time during some heavy testing with binding, app and Postman performing requests simultaneously. FYI @openhab/add-ons-maintainers

[lolodomo]

LGTM, thank ypu