Fix settings request when `retrieve_choices_function()` fails

[rytilahti]

Accessing choices_attribute of the enumsettingdescriptor may cause an exception.

DEBUG:miio.miioprotocol:192.168x.x:54321 >>: {'id': 207, 'method': 'get_multi_maps_list', 'params': []}
DEBUG:miio.miioprotocol:192.168x.x:54321 (ts: 2023-01-30 13:09:12, id: 207) << {'id': 207, 'result': 'unknown_method'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tpr/code/python-miio/miio/device.py", line 349, in sensors
    self._initialize_descriptors()
  File "/home/tpr/code/python-miio/miio/device.py", line 236, in _initialize_descriptors
    self._settings = self._setting_descriptors_from_status(status)
  File "/home/tpr/code/python-miio/miio/device.py", line 201, in _setting_descriptors_from_status
    setting.choices = retrieve_choices_function()
  File "/home/tpr/code/python-miio/miio/integrations/roborock/vacuum/vacuum.py", line 388, in _map_enum
    maps = self.get_maps()
  File "/home/tpr/code/python-miio/miio/click_common.py", line 185, in _wrap
    return func(self, *args, **kwargs)
  File "/home/tpr/code/python-miio/miio/integrations/roborock/vacuum/vacuum.py", line 380, in get_maps
    self._maps = MapList(self.send("get_multi_maps_list")[0])
  File "/home/tpr/code/python-miio/miio/integrations/roborock/vacuum/vacuumcontainers.py", line 112, in __init__
    for map in self.data["map_info"]:
TypeError: string indices must be integers

Originally posted by @rytilahti in #1701 (comment)

[starkillerOG]

I think this will resolve itself once #1685 is merged

We schould make a try-except inside the _setting_descriptors_from_status around the retrieve_choices_function.
To catch UnsupportedFeatureException.

I will make this PR once #1701 and #1685 are merged

[rytilahti]

It would be better if the attribute access would do no I/O at all. Or at least, as the name (choices_attribute) suggests, what's behind the name should not be a callable but an attribute. In any case, I don't think this is blocking anything right now so it can wait.

[starkillerOG]

Well in the case of the roborock map_list we need to do I/O to get the amount and names of the maps to which we can switch. This info can only be retrieved from the vacuum using I/O. I don't see a way around that.

[rytilahti]

But if the regular update cycle retrieves that data (as discussed briefly in that other PR), it would be already available in whatever container the information from the map list command is stored :-)

[starkillerOG]

But if the regular update cycle retrieves that data (as discussed briefly in that other PR), it would be already available in whatever container the information from the map list command is stored :-)

Yes that could work if we would make the call to retrieve the map data part of the main update cycle.
I think I am starting to get what you mean.