Add rust-required-checks

[blaginin]

Which issue does this PR close?

Related to #6880

Rationale for this change

When we were testing merge queues for this repo, I made all "rust test" steps mandatory. However, those "rust tests" weren't running for PRs that change documentation only - and as a result it was impossible to merge those PRs: #17183 (comment)

GitHub doesn't have a way to pair merge queues with paths-ignore: https://github.com/orgs/community/discussions/45899 - so I had to move those checks to a separate step (this is how this problem is solved by the community).

I'm using dorny/paths-filter as it has already been approved by ASF and it is desired for us to use it.

You'll notice predicate-quantifier is marked as an unsupported arg:

This arg is actually used, just not defined in the action definition. Once a release with dorny/paths-filter#279 is created, we'll switch to the new version and the warning will go away.

What changes are included in this PR?

A new action, rust-required-checks, that will become mandatory (requirement to enable merge queues):

• When there are rust changes, it'll be "green" only when all the previous steps are green
• When there are no rust changes, it gets green right away so we won't have to wait

Are these changes tested?

Yes:

• Failed change: dorny: failed rs change datafusion-sandbox#144
• Successful change with rs updates: dorny: rs change datafusion-sandbox#143
• md-only updates: dorny: md change datafusion-sandbox#142

Are there any user-facing changes?

No

[Jefffrey]

I'll take a look at this soon; related, but I've been seeing cases where clicking Merge when ready on an already approved + CI passing PR doesn't add it to the merge queue. It seems to require approving after auto merge is enabled for the PR 🤔

Would this fix that?

[Jefffrey]

Quite the workaround, wish GitHub had better native support for this 😅

[alamb]

This PR was approved but not yet merged. I am trying to clean up the review / merge queue so I'll mark it as draft. No rush or pressure, but do we know what is the plan here?

[blaginin]

yes! sorry, it's on me - my plan is to finish the workers upgrade first, because as a result of the merge queue some actions will become required, so if CI isn't stable we won't be able to merge. Hence, focusing on stability first

[alamb]

yes! sorry, it's on me - my plan is to finish the workers upgrade first, because as a result of the merge queue some actions will become required, so if CI isn't stable we won't be able to merge. Hence, focusing on stability first

Makes a lot of sense to me -- thank you for your work in this area