feat: add support for resolution mapping

[NorbertNader]

Overview

This will allow customers to specify they want to fetch aggrgated data and the resolution mapping for the aggregated data.

The resolutionMapping maps the requested viewport date range to a specific resolution for the aggregation function.
The key is a number represented in milliseconds for the viewport duration. The value is the desired resolution that can be any string or number.

The reason the resolution mapping is flexible when it comes to the resolution is because different data sources might have different api signatures for the resolution. E.g. SiteWise uses '1h|1m|1d' as valid resolutions. Another api might want to use number representing milliseconds or nanoseconds. It is up to the data source to implement how to determine the resolution based on this mapping.

Next steps

Add support for multiple aggregation types in the cache. This will allow subscriptions made to the same data source to not have the cache cleared/overwritten leading to erroneous data e.g. If we have two subscriptions made to the same data source one for AVERAGE and the other for COUNT, we do not want them to affect each other and have them cached separately.

Tests

https://github.com/awslabs/iot-app-kit/runs/4434958580?check_suite_focus=true

Legal

This project is available under the Apache 2.0 License.

[diehbria]

if a user requests some data that is aggregated by average, and then then updated to aggregate by count, would the data-module provide the previously cached data requested under 'average' to the subscriber looking for count?

[NorbertNader]

if a user requests some data that is aggregated by average, and then then updated to aggregate by count, would the data-module provide the previously cached data requested under 'average' to the subscriber looking for count?

Yes, that is exactly what would happen. Good callout, thanks for bringing this up! I think we’ll want to address this. There are two ways we can approach this that I can think of:

1. When the subscription is updated with a different aggregation type, we clear the cache. This is the fast solution and probably what I would recommend at this time.
2. A more long term solution would be to support multiple aggregation types in the cache. I think that is something we will want to do but out of the scope of this PR.

[gareth-amazon]

2. A more long term solution would be to support multiple aggregation types in the cache. I think that is something we will want to do but out of the scope of this PR.

I would just do that in the next PR. What is #1 going to buy us in the short term?

[NorbertNader]

2. A more long term solution would be to support multiple aggregation types in the cache. I think that is something we will want to do but out of the scope of this PR.

I would just do that in the next PR. What is #1 going to buy us in the short term?

Solution 1. would allow us to move forward but has other concerns we I discussed offline with @diehbria . If we have two subscriptions one to AVERAGE and then add another one for COUNT, that would clear the cache for the first subscription leading to erroneous data since they would both be getting COUNT while the first subscription is expecting AVERAGE.

That is why instead we are dropping the aggregateType completely for now since that is something we would have to tackle first. I have updated the overview with the next steps highlighting this issue. For now my proposal is to go with a fetchAggregatedData boolean and the resolutionMapping