Promote join_kind from detail namespace to public

[PointKernel]

Description

This PR promotes join_kind from the detail namespace to the public API, as it will be used by the upcoming filter_join_indices API. No functional code changes are involved.

Needed by #20385

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[PointKernel]

/ok to test 252f730

[bdice]

Looks fine. In the new features, will we be moving towards a single API that exposes the join type as an argument? Will we want to do the same with other existing join algorithms? Let’s discuss design options and particularly any gaps in the matrix of join algorithms and supported join types, if we are heading in that direction. Possibly a good brown bag discussion but I’d like to have an issue discussing plans for the future state, for posterity.

[PointKernel]

will we be moving towards a single API that exposes the join type as an argument?

Probably not. The only reason to expose this is to allow a unified filter_join_indices together with hash_join::inner/left/full_join, so we can replicate the behavior of mixed_inner/left/full_join. There are currently no plans to modify the existing join algorithms.