dynamic scheduledRefreshContexts behavior

[vkruoso]

Describe the bug
When using the scheduledRefreshContexts function to provide a list of tenants to cube, the pre-aggregations partition data refresh stops working in some cases.

Our list of tenants is read from a Redis database. When the driverFactory function is called for a tenant, we add that tenant to the Redis cache for a specific time (1hr TTL for instance). The refresh worker will pick it up for pre-aggregation builds during the refresh interval. When the TTL expires and the key is no longer part of the security contexts, naturally the refresh worker will stop refreshing. The issue is that if that customer comes back it is necessary to kick-off again the partition refresh procedure and it seems it never does, even tough the driverFactory function is called again and the key is added to Redis again.

To Reproduce
Steps to reproduce the behavior:

1. Create custom driverFactory function that returns a driver for each tenant and saves the tenant in Redis with TTL
2. Run queries to check that partitions are build and that the refresh works
3. Wait until the TTL expires
4. Run more queries and check that the tenant was added to redis, but partitions are not refreshed

Expected behavior
That when tenants are added or removed from scheduledRefreshContexts results, the system would still behave as it should regarding partitions refreshes.

[paveltiunov]

@vkruoso Just checked the code and there's no caching around scheduledRefreshContexts. I'd appreciate if you can reproduce it in Cube Cloud.