MCR-3581! Improve factory methods in mycore-acl

[golsch]

Link to jira.

Pull Request Checklist (Author)

Please go through the following checklist before assigning the PR for review:

Ticket & Documentation

• The issue in the ticket is clearly described and the solution is documented.
• Design decisions (if any) are explained.
• The ticket references the correct source and target branches.
• The fixed-version is correctly set in the ticket and matches the PR's target branch (main).

Feature & Improvement Specific Checks

• Instructions on how to test or use the feature are included or linked (e.g. to documentation).
• For UI changes: before & after screenshots are attached.
• New features or migrations are documented.
• Does this change affect existing applications, data, or configurations?
  • Yes: Is a migration required? If yes, describe it.
  • Breaking change is marked in the commit message.

Testing

• I have tested the changes locally.
• The feature behaves as described in the ticket.
• Were existing tests modified?
  • Yes: explain the changes for reviewers.

MCR Conventions & Metadata

• MCR naming conventions are followed
• If the public API has changed:
  • Old API is deprecated or a migration is documented.
  • If not, no action needed.
• Java license headers are added where necessary.
• Javadoc is written for non-self-explanatory classes/methods (Clean Code).
• All configuration options are documented in Javadoc and mycore.properties.
• No default properties are hardcoded — all set via mycore.properties.

Multi-Repo Considerations

• Is an equivalent PR in MIR required?
  • If yes, is it already created?

[toKrause]

Would you consider renaming this class MCRAccessKeyServiceManager? Even though it currently only provides access to the configured MCRAccessKeyService, this class might be a good home for potential future methods that work with MCRAccessKeyService instances.

It would also more closely follow existing naming conventions established in MyCoRe, for example: MCRPIServiceManager, MCRProcessableManager, MCRTikaManager.

[toKrause]

Or, to avoid holding a singleton instance in a class other then the singletons class altogether (which is unusual from a design-pattern perspective and afaik. currently done nowhere else in MyCoRe), remove this class and put the singleton holder into the interface, see MCRObjectQueryResolver.

(Even better would be not having polymorph singletons, but I think that ship has sailed in MyCoRe a long time ago.)