Transformations: De-emphasize non-applicable transformations

[codeincarnate]

What is this feature?

This PR adds support to transformations for an applicator function which can be used to determine if the transformation is applicable to the current data.

Why do we need this feature?

Many transformations have base conditions needed for them to work correctly. Currently however, we don't do any checks to see if these base conditions are met. This makes for a confusing experience, as it's currently only possible to tell through experimentation or from prior knowledge what given transformations will work on a given data set.

Who is this feature for?

Users of transformations

Which issue(s) does this PR fix?:

Fixes #74199

Special notes for your reviewer:

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[codeincarnate]

Oops, forgot to put this in draft 😢. Still needs a little to hammer out.

[joshhunt]

neat! 📸

[oscarkilhed]

Nice! Will review in the morning!

[codeincarnate]

Added a few things:

• Moved to applicability levels. Under the hood there are four right now, but we reduce that to two. (i.e. we ignore the impossible outcome and the highly applicable outcome)
• Adds HighlyApplicable, which would allow transformations to be highlighted in the future based on data (i.e. promote heatmap if heatmap data is found)
• Updates the display to show a grayscale icon if disabled, add disabled to the title, and to add an info icon which contains the applicability message to help the user understand the source of the error.

Currently although they're marked as disabled they can still be used as we don't wish to make these unusable for cases that we haven't taken into account.

[codeincarnate]

@ryantxu if you could take another look it would be greatly appreciated. I moved to the applicability levels per your suggestion and I think we can get quite a lot from this! Would be great to know your thoughts in regard to the implementation there.

[oscarkilhed]

This is looking good!
There's a few other transformations that don't really work with all kinds of data. TimeSeriesToTable for instance, doesn't work with multiple fields in the same series. But adding and tuning these rules could be left for follow up PRs i guess.

[oscarkilhed]

Two thoughts.
Maybe it's a good idea to sort the disabled transformations to the bottom. I also wouldn't mind if they were a bit more de-emphasized, the gray-scale on the icons is nice, but it's not super obvious.

The transformations are still selectable. I'm a bit torn on this, I think right now they need to be enabled, because there is no way to insert a transformation between two transformations, a transformation could be applicable before one of the applied transformations, but not after it. But it's also a bit weird having a transformation say that it's disabled but you can still apply it.

[codeincarnate]

Thanks for the comments Oscar!

1. In terms of the conditions, I was hoping to get a decent base set. I think we can go pretty arbitrarily deep in this so didn't go crazy for this PR.
2. In terms of the sorting to the bottom, there was some concern that they would end up being somewhat hidden. Given that we are pushing to move to a drawer interface for new transformations though this may be ok. I'll circle back with @catherineymgui about that.
3. I'll play with some ways to make things look less uhhh selectable 😆

[codeincarnate]

@mdvictor @oscarkilhed if you could take another look at the presentation it could be appreciated 🙏

[oscarkilhed]

Looks good! 🎉