Adjust granularity automatically only if necessary

[adrianmroz]

Right now when changing anything in time filter, granularity of time split is adjusted by RulesEvaluator and often it changes granularity unnecessarily.

Goal should be to:

1. If user changed granularity we should keep it as long as possible.
2. We should change it if it doesn't make sense
3. We should change it for performance reasons
4. We should change it if data granularity is bigger than granularity setting

At first, we need to check what's possible with current implementation of RulesEvaluator.

[adrianmroz]

Granularity is decided there: https://github.com/allegro/turnilo/blob/08d1a160b14838e30ac69f7173ec3e20c04e5d63/src/common/models/splits/splits.ts#L123-L153

This method is called whenever splits change or filters change. We should limit that.

[adrianmroz]

Hmm, looks like we have a bug there - we search clause by type, we should search by split reference and type. https://github.com/allegro/turnilo/blob/08d1a160b14838e30ac69f7173ec3e20c04e5d63/src/common/models/splits/splits.ts#L136

[adrianmroz]

Observations:

• We don't use data values when finding best bucketing. That probably implies that bucketing should be changed only when changes filter on the same dimension.

• We don't have information about previous bucketing source. Was it calculated by turnilo or selected by user? Keeping such information wouldn't be trivial.

• Right now after changing filter, all splits that refers to changed clause have their bucketing set to null. Because of that, later in updateWithFilter we don't have previous bucketing and we couldn't compare it to newfound.

• Interesting tidbit: when converting to "specific" ("non relative") filter, we also reset bucketing. That's happening when sharing fixed url.

[adrianmroz]

Probably linked with #598