refactor(gradle)!: Split out authentication utilities to a new module

[sschuberth]

This allows for more fine-granular dependency management.

BREAKING CHANGE: Programmatic users might need to depend on authorization-utils instead of / in addition to ort-utils now.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.42%. Comparing base (555bc12) to head (f671a99).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #11925      +/-   ##
============================================
- Coverage     58.60%   58.42%   -0.19%     
+ Complexity     1809     1807       -2     
============================================
  Files           359      361       +2     
  Lines         13387    13491     +104     
  Branches       1355     1382      +27     
============================================
+ Hits           7846     7882      +36     
- Misses         5049     5114      +65     
- Partials        492      495       +3     

Flag	Coverage Δ
funTest-external-tools	14.66% <ø> (-0.01%)	⬇️
funTest-no-external-tools	30.24% <ø> (-0.45%)	⬇️
test-ubuntu-24.04	41.76% <ø> (-0.13%)	⬇️
test-windows-2025	41.73% <ø> (-0.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fviernau]

Regarding the 2nd commit, I'm not sure about all filename changes.
Utils become more specific, so it will be harder to find a place for a new utility function if the existing name does not fit.

In particular, for Utils, which only have very few functions in it, this refactoring in my view may be a little bit early, because it becomes clearer what utilities will be about once it has grown a bit further.

Also in some cases this name introduces redundancy. E.g. in case of NodeUtils.

What do you think? (maybe it's worth to split out this commit)

Also, does this approach really fix an issue with finding things in IDE. It maybe be just me, but I wouldn't be able to remember the filenames corresponding to a function of all these more specific utility filenames anymay.

[sschuberth]

Utils become more specific, so it will be harder to find a place for a new utility function if the existing name does not fit.

I get what you mean. But to some extend, I believe it could also be good to require us thinking a bit mode about modularity and proper grouping of functions (by functionality, not by type).

Also in some cases this name introduces redundancy. E.g. in case of NodeUtils.

I agree that "Node" is a bit redundant, but we already have such "doubling" e.g. in

utils/authentication/src/main/kotlin/AuthenticationUtils.kt

So I weighted disambiguation higher than getting rid of a bit of redundancy.

I wouldn't be able to remember the filenames

I don't think that's required. All but one renaming keep "Utils" as part of the filename, so you would still only need to search for "Utils", but get more telling names in the search results.