refactor!: unifier renamed to finalizer

[dadrus]

Related issue(s)

relates to #882

Checklist

• I agree to follow this project's Code of Conduct.
• I have read, and I am following this repository's Contributing Guidelines.
• I have read the Security Policy.
• I have referenced an issue describing the bug/feature request.
• I have added tests that prove the correctness of my implementation.
• I have updated the documentation.

Description

Initially, unifiers were acting on a Subject object only. For that reason the name unifier has been chosen to reflect their purpose - to unify the information about the subject into a format required by the upstream service.

Meanwhile, unifiers has access to the Request object as well and it is up to the integrator, how to configure them. There are cases, where the upstream service doesn't need any information about the subject, but just a specific header from the original request.

In the future, when #882 is implemented, heimdall can be used to make use of e.g. API keys or drive OAuth2 Client Credentials Flow to get a token required for communication with an upstream service in the last step of the pipeline, which is completely independent from the subject authenticated so far.

That also means, the name unifier has already lost its initial meaning and will lead to even more confusion in the future. For that reason, this PR renames the last step of the pipeline to finalizer, which is also a breaking change.

For the heimdall's configuration file that change means

rules:
  mechanisms:
    unifiers:
      <list of unifiers>

become

rules:
  mechanisms:
    finalizers:
      <list of finalizers>

And for the rule sets, that change means, that finalizers are referenced by the key word finalizer (was unifier before).

So

execute:
  # other referenced mechanisms
  - unifier: whatever

become

execute:
  # other referenced mechanisms
  - finalizer: whatever

[codecov]

Codecov Report

Merging #956 (e2e6edd) into main (eeb5a82) will decrease coverage by 0.01%.
Report is 2 commits behind head on main.
The diff coverage is 98.01%.

@@            Coverage Diff             @@
##             main     #956      +/-   ##
==========================================
- Coverage   89.82%   89.82%   -0.01%     
==========================================
  Files         234      234              
  Lines        9652     9650       -2     
==========================================
- Hits         8670     8668       -2     
  Misses        762      762              
  Partials      220      220              

Files	Coverage Δ
internal/handler/decision/request_context.go	100.00% <100.00%> (ø)
...nal/handler/envoyextauth/grpcv3/request_context.go	96.93% <100.00%> (ø)
internal/handler/proxy/request_context.go	91.58% <ø> (-0.08%)	⬇️
internal/rules/mechanisms/factory_impl.go	100.00% <100.00%> (ø)
...rnal/rules/mechanisms/finalizers/config_decoder.go	78.57% <ø> (ø)
...al/rules/mechanisms/finalizers/cookie_finalizer.go	89.47% <100.00%> (ø)
...al/rules/mechanisms/finalizers/header_finalizer.go	89.47% <100.00%> (ø)
...ernal/rules/mechanisms/finalizers/jwt_finalizer.go	96.17% <100.00%> (ø)
...rnal/rules/mechanisms/finalizers/noop_finalizer.go	100.00% <100.00%> (ø)
internal/rules/rule_factory_impl.go	97.29% <100.00%> (ø)
... and 3 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more