feat: NET-3663 add endpoint owners/get

[tpurschke]

Summary

Adds the /api/owners/get middleware endpoint for issue #4778.

Changes

Owners endpoint

• Adds a filtered owner GraphQL query (getOwnersFiltered) and wires it into OwnerQueries.
• Adds OwnersController with role restriction to admin, auditor, and modeller.
• Supports optional AND-combined filters for owner id, lifecycle state id, active flag, owner name, and external app id.
• Supports wildcard matching for name and appIdExternal using * and ?.
• Restricts modeller calls to owner ids from the x-hasura-editable-owners JWT claim.
• Adds showDetails: when omitted/false only core fields are returned; when true the full owner detail set is returned (GetOwnerResponse).
• Adds showOnlyActiveState: by default owners whose lifecycle state is inactive are filtered out (owners without a lifecycle state are kept); set to false to include inactive-state owners.
• Owner type is derived from appIdExternal: standard when the external app id contains app (case-insensitive), infrastructure otherwise (including owners without an external app id).
• Extends the ownerDetails fragment and FwoOwner with the owner lifecycle state (id, name, active_state).
• Adds Swagger XML remarks with filtered request examples, response examples, and documented 401/403/500 responses.

Owner report (ReportOwners)

• Adds the owner lifecycle state to the existing owner report output: two new columns ("Production state Id" / "Production state Name") in both the HTML and CSV exports. This surfaces the newly fetched lifecycle-state field in the existing report and is reflected in the updated ExportTest expectations.

Documentation (off topic)

• consolidated the revision history documentation here as well (only one file instead of -develop and -main
• removed entries <8.0

Tests

• Adds OwnersControllerTest covering route/auth metadata, filter variables, wildcard conversion, modeller scoping, showDetails/showOnlyActiveState behavior, owner-type classification, and response type mapping.
• Updates ExportTest and SimulatedUserConfig for the new owner lifecycle state fields.

[Elutrixx]

Personal Feedback: In my head this is missing a validation layer before data given by the third party is used. This was a problem with my first GetRulesByFilter endpoint that I tried to fix in my newer set of endpoints and has lead to several "bugs" that were simply uncaught validation problems. It CAN be ignored but its debatable wheter it should.

Relevant Feedback
Medium: the name/appId filters do not match the documented wildcard contract. In OwnersController.cs:229-234, BuildLikePattern() converts * and ? but leaves raw % and _ untouched, so a plain search term such as APP_1 behaves like a broader SQL pattern instead of a literal contains search. The controller remarks say only * and ? are wildcards, so % and _ need escaping before _ilike is sent.

Open Questions:
Was this tested on the customer machine? The SQL patterns seem rather intricate to me so it might be useful to check if they work with varying infrastructure as well

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tpurschke]

Personal Feedback: In my head this is missing a validation layer before data given by the third party is used. This was a problem with my first GetRulesByFilter endpoint that I tried to fix in my newer set of endpoints and has lead to several "bugs" that were simply uncaught validation problems. It CAN be ignored but its debatable wheter it should.

Relevant Feedback Medium: the name/appId filters do not match the documented wildcard contract. In OwnersController.cs:229-234, BuildLikePattern() converts * and ? but leaves raw % and _ untouched, so a plain search term such as APP_1 behaves like a broader SQL pattern instead of a literal contains search. The controller remarks say only * and ? are wildcards, so % and _ need escaping before _ilike is sent.

Open Questions: Was this tested on the customer machine? The SQL patterns seem rather intricate to me so it might be useful to check if they work with varying infrastructure as well

• included your suggestions regarding validation
• escaped wildcards we do not support
• tested succesfully with K001 data