Trino Helm charts should be deployed in Trino CI to determine if there are breaking changes

[joshthoward]

Periodically there are breaking changes in Trino that cause failures when deploying the Trino Helm charts. To detect these changes sooner, we should deploy the Trino Helm charts in Trino CI as a smoke test to detect breaking changes.

[nineinchnick]

When writing the description in #11416 I started wondering if it makes sense at all. Blocking the pipelines here would prevent making breaking changes, but sometimes we have to. Charts are a downstream artifact that needs to be updated later. Maybe we should be only triggering workflows in the trinodb/charts repo?

I'll see if it's possible to set-up a dependabot for Docker images.

[nineinchnick]

Or running workflows on a schedule. It's already using the latest tag by default.

[hashhar]

I'm working to add matrix of trino versions to both the python client and helm charts. (Python client already has matrix but it needs improvements).

It'll catch breakage once a new version is available and we can release new chart/clients with fixes then. With the low number of breaking changes we make I don't believe it's worth the effort to think too much about this just yet.