Maybe get_recommended_labels should take a struct of named arguments

[nightkr]

The current list of string arguments is confusing to follow (especially if you don't use rust-analyzer with parameter inlays), and is confusing and error-prone to update in operators when new arguments are added (often in the middle of the list).

This PR adds another parameter to the list: https://github.com/stackabletech/operator-rs/pull/492/files#diff-f3a8a77aa3434fb4aef8eb9c3d011832fc27301972b9975aa303832c3ed33675 Clippy also complains about the many parameters.

This is the function in its current state: https://github.com/stackabletech/operator-rs/blob/main/src/labels.rs#L22

Acceptance criteria:

• get_recommended_labels does not take so many arguments
• with_recommended_labels also

[nightkr]

I actually kind of think even just doing the easy "struct of &strs would be a huge improvement, but I believe @siegfriedweber had strong opinions here so I'll wait for him to return...

[siegfriedweber]

A struct would be an improvement because the field names help to assign the correct values and the struct can be reused so that repetition is reduced.

I had a more elaborate solution in mind where you just pass the cluster spec and a "controller spec" where the recommended labels are derived from. The ClusterResources already contain some of the required information. The application version could be made accessible via a Trait. The labels for the role and role-group could be extracted into another builder function because not all resources are at a role-group level and they currently use "global" as a placeholder. If the recommended labels do not match exactly what the caller needs then she or he can overwrite them with other functions in the ObjectMetaBuilder.

But after a closer look, the implementation of my solution is not as straight forward as I hoped. So I am also fine with the easy struct solution.

[nightkr]

Is there much further refinement planned here then?

[fhennig]

We could still use a trait instead of a struct and then in the trait we could implement functions like the superset_version and we could hardcode some things in there, instead of having the OPERATOR_NAME static vars etc.

But it's not a strong opinion

[fhennig]

I just asked Sigi and he said a Trait might be nice, but he'd leave it up to the implementor.

[fhennig]

I've added 2 acceptance criteria

[lfrancke]

The description does not really talk about the solution but the details are in the comments so I'm fine with it.