feat!: Pipeline handler identifier are present in error context to support pipeline handler specific error handling strategies

[dadrus]

closes #97
closes #156
closes #211
closes #212

This PR updates the implementation of error handlers and enables referencing of pipeline handlers via their IDs.

Before this PR the error matching definition was:

error:
  - authentication_error
  - authorization_error
  - ...

This PR changes it to the following:

error:
  - type: authentication_error
    raised_by: <pipeline handler id>
  - type: authorization_error

If raised_by (which is optional) is specified the condition is specific for the referenced pipeline handler, otherwise, the error matching happens irrespective of the pipeline handler raising the given error type.

This allows implementation of different error handling strategies for the same error type in one rule for different pipeline handler. E.g. to implement two different oauth2 authentication schemes in the same rule (for the same matching url, which was not possible before this PR), one can define the handlers as follows:

authenticators:
  - id: oauth2_authenticator_1
    type: oauth2_introspection
    config:
      ...
  - id: oauth2_authenticator_2
    type: oauth2_introspection
    config:
      ....
  - <other authenticators>
error_handlers:
  - id: eh_1
    type: <whatever type is required>
    config:
      <type specific config>
      when:
        - error:
            - type: authentication_error
              raised_by: oauth2_authenticator_1
          <other error conditions>
  - id: eh_2
    type: <whatever type is required>
    config:
      <type specific config>
      when:
        - error:
            - type: authentication_error
              raised_by: oauth2_authenticator_2
          <other error conditions>

and then make use of these in a rule, like follows:

- id: rule:1
  url: https://my-service1.local/<**>
  methods: [ "GET" ]
  execute:
    - authenticator: oauth2_authenticator_1
    - authenticator: oauth2_authenticator_2
 on_error:
   - error_handler: eh_1
   - error_handler: eh_2

With the definition above the eh_1 error handler will only kick in if an authentication_error has been raised by oauth2_authenticator_1 and not any other pipeline handler. Same is true for the eh_2 error handler, which will only kick in if an authentication_error has been raised by oauth2_authenticator_2.

IMPORTANT: Heimdall does not verify the integrity of the pipeline handler identifiers configured using raised_by on start or while loading rules. Thus, if there is no pipeline handler with the given identifier, the error will not match. This limitation might be addressed in a future PR.

[codecov]

Codecov Report

Merging #239 (d995e3e) into main (6b62b47) will decrease coverage by 0.05%.
The diff coverage is 76.84%.

@@            Coverage Diff             @@
##             main     #239      +/-   ##
==========================================
- Coverage   85.26%   85.21%   -0.06%     
==========================================
  Files         159      156       -3     
  Lines        6332     6383      +51     
==========================================
+ Hits         5399     5439      +40     
- Misses        791      810      +19     
+ Partials      142      134       -8     

Impacted Files	Coverage Δ
...e/errorhandlers/matcher/error_condition_matcher.go	100.00% <ø> (ø)
internal/pipeline/mutators/cookie_mutator.go	83.33% <64.28%> (-2.09%)	⬇️
internal/pipeline/mutators/header_mutator.go	83.33% <64.28%> (-2.09%)	⬇️
...l/pipeline/authenticators/generic_authenticator.go	89.26% <65.62%> (-2.76%)	⬇️
...thenticators/oauth2_introspection_authenticator.go	88.75% <66.07%> (-3.39%)	⬇️
internal/pipeline/authorizers/remote_authorizer.go	80.59% <66.27%> (-3.66%)	⬇️
internal/pipeline/hydrators/generic_hydrator.go	81.20% <67.69%> (-4.33%)	⬇️
internal/pipeline/mutators/jwt_mutator.go	87.91% <75.00%> (-4.33%)	⬇️
...ernal/pipeline/authenticators/jwt_authenticator.go	91.55% <83.82%> (-1.16%)	⬇️
...pipeline/authenticators/anonymous_authenticator.go	92.30% <87.50%> (+0.87%)	⬆️
... and 17 more

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