api: permit verbose body error message

[ndr-brt]

What this PR changes/adds

Permits verbose response message in case of failure. This will be configurable with a setting that's false by default

Why it does that

To give a detailed reason to the client, that will permit a better understanding of the failure.

Further notes

• Moved EdcApiException and subclasses to the web-spi module
• Moved EdcApiExceptionMapper to the jersey module and loaded by default on every context.
• Renamed CorsFilterConfiguration to JerseyConfiguration with the additional setting about verbose response.
• Added README for the jersey module

Linked Issue(s)

Closes #1411

Checklist

• added appropriate tests?
• performed checkstyle check locally?
• added/updated copyright headers?
• documented public classes/methods?
• added/updated relevant documentation?
• added relevant details to the changelog? (skip with label no-changelog)
• formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

[codecov-commenter]

Codecov Report

Merging #1479 (256a6c7) into main (1b4e718) will increase coverage by 0.06%.
The diff coverage is 75.86%.

@@            Coverage Diff             @@
##             main    #1479      +/-   ##
==========================================
+ Coverage   67.40%   67.47%   +0.06%     
==========================================
  Files         719      712       -7     
  Lines       16032    16020      -12     
  Branches     1061     1063       +2     
==========================================
+ Hits        10806    10809       +3     
+ Misses       4747     4732      -15     
  Partials      479      479              

Impacted Files	Coverage Δ
...onnector/api/auth/AuthenticationRequestFilter.java	100.00% <ø> (ø)
...ctor/api/auth/TokenBasedAuthenticationService.java	100.00% <ø> (ø)
...r/api/datamanagement/asset/AssetApiController.java	84.09% <ø> (ø)
...tractagreement/ContractAgreementApiController.java	100.00% <ø> (ø)
...actdefinition/ContractDefinitionApiController.java	90.69% <ø> (ø)
...tnegotiation/ContractNegotiationApiController.java	90.16% <ø> (ø)
...nagement/policy/PolicyDefinitionApiController.java	80.64% <ø> (ø)
.../transferprocess/TransferProcessApiController.java	88.67% <ø> (ø)
...aplane/selector/DataPlaneSelectorApiExtension.java	100.00% <ø> (ø)
.../transfer/provision/http/HttpWebhookExtension.java	83.87% <ø> (-0.51%)	⬇️
... and 14 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1b4e718...256a6c7. Read the comment docs.

[jimmarino]

I'm good with this PR but think we need to improve error reporting further. The default runtime behavior should be to return actionable error messages when invalid data is sent. For example, a client not under the control of the EDC operator may send a message containing invalid data. The response returned by the EDC should assist the client in diagnosing why the data is invalid.

This can be done by:

1. Modifying the EdcApiExceptionMapper to handle messages returned by ConstraintViolationException. These messages should be returned as a payload containing a defined JSON error object.
2. All constraint annotations used by EDC should contain a message. Eventually, the message should be i18n-enabled via configuration but maybe not in the first go-around.
3. This behavior should be enabled by default. If we want extended debug information, that could be optionally enabled.

@ndr-brt what do you think?

[ndr-brt]

@jimmarino I agree this could improve, in particular:

1. Yes, currently the json payload structure for the ConstraintViolationException is defined by the ValidationErrorData class located in the validation library, we need to define a common structure for all the errors.
2. I wasn't aware of the possibility to have a custom message on the annotations, totally agree on this.
3. Makes sense. What could be an "extended debug information"? Do you mean attaching the stack trace to the message for example? (that's something that needs to be avoided in production but could be useful for debug.

will create the issues accordingly