Flex context sensors are not handled correctly in scheduler yet when used as fallback attributes

[nhoening]

To replicate: set "Site Consumption Capacity" field of an asset to a sensor, and attempt to create a schedule (e.g. using the toy tutorial)

In the line below, asset.get_attribute() was extended to return also flex context fields:
https://github.com/FlexMeasures/flexmeasures/pull/1293/files#diff-9a3e4dca97ba0f73dab16ea74e2711fdbf6cbb3c6a0fe71784ec52f26df2f7a0R331

The scheduler will try to read data for attributes with get_continuous_series_sensor_or_quantity(), also using fallback attributes, which in my case (the site-consumption-capacity field is set in the flex context, as sensor) turns out to be something like {"sensor": 26}, and fail.

This is what I see when testing scheduling (from CLI): HANDLING RQ SCHEDULING WORKER EXCEPTION: <class 'TypeError'>:Invalid magnitude for Quantity: {'sensor': 26}

We could support that these utils understand the sensor structure, or we rethink the idea that flex context fields are available as asset attributes. I don't know why it was needed.
We could give asset.get_attribute() a parameter (values_only) to avoid this kind of lookup.
But in general, I believe users probably believe they receive some value with an attribute lookup, not a sensor spec.

Opinions?

[nhoening]

Tagging @Flix6x and @victorgarcia98 to help me sort out what the right follow-up would be. I hope I added viable options at the end.

[Flix6x]

In my opinion:

• The fallback fetching logic should be adapted to support sensor references.
• The fallback logic should be adapted to look for the relevant field in the db flex-context only (which is where our db migration moved them to).