⚡ [REST API] Block execution on XML/JSON parsing errors and report 400 error code

[Agnul97]

With this PR I changed the MOXy exception handling in a way that improves error responses when XMLs/JSONs provided via rest API cannot be parsed correctly.

ACTUAL SITUATION

Currently, in the case when a field in the XML sent via rest API is not parsable, its value is set to null by MOXy and only then the "*Service" class (for example deviceService) perform checks on non-null fields and, eventually, throws an exception.
If this could seem reasonable, it creates some scenarios when this behaviour is wrong.

For example, assume that I want to update the expiration date of a user. I would then call the endpoint /{scopeId}/users/{userId} specifying the new expirationDate field in the request body. If I erroneously set a wrong / not parsable value for it (for example, a wrong random string), the "userService" class will receive the expirationDate value as null, interpreting this a request to set an "unlimited" expiration date (just as If I had made the request without the field, with the purpose to remove the expirationDate of the user)

There are other cases like this, that can be summarized as an impossibility of the code to differentiate the case where we provide a field that cannot be parsed (set "null" by MOXy) from the case when a field has not been provided in the request (set to "null" also in this case) or actually set to null by the client. I wanted to change the code in order to differentiate these cases and be able to alert the client when the provided XML contains not parsable fields OR when a mandatory provided field is missing/null.

PROVIDED SOLUTION

I changed our MOXy configuration introducing a custom "MoxyJsonProvider" that tweaks the internal "validationEventHandler". In this way, a different exception handling is performed internally and exceptions are propagated to the stack instead of being caught. These exception are then handled by the "EclipseLinkExceptionMapper" Class in order to return to the client an appropriate response.

EXAMPLE RESPONSE IN CASE OF PARSING ERRORS

In the example of a user update as presented above, assuming that we are updating a user that has an expiration date in the future, this is what happens now:

Before this PR, this request would have removed the expiration date of this user

[codecov]

Codecov Report

Attention: Patch coverage is 7.14286% with 26 lines in your changes missing coverage. Please review.

Project coverage is 16.80%. Comparing base (ca43672) to head (be39606).
Report is 15 commits behind head on develop.

Files with missing lines	Patch %	Lines
...ommons/rest/errors/EclipseLinkExceptionMapper.java	0.00%	16 Missing ⚠️
...app/api/web/MoxyJsonFeatureCustomJsonProvider.java	0.00%	10 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop    #4117      +/-   ##
=============================================
- Coverage      16.81%   16.80%   -0.01%     
  Complexity        22       22              
=============================================
  Files           2019     2021       +2     
  Lines          52437    52463      +26     
  Branches        4423     4424       +1     
=============================================
  Hits            8815     8815              
- Misses         43224    43250      +26     
  Partials         398      398              

Files with missing lines	Coverage Δ
...eclipse/kapua/app/api/web/RestApisApplication.java	55.17% <100.00%> (ø)
...kapua/model/xml/adapters/XmlPropertiesAdapter.java	94.87% <100.00%> (ø)
...app/api/web/MoxyJsonFeatureCustomJsonProvider.java	0.00% <0.00%> (ø)
...ommons/rest/errors/EclipseLinkExceptionMapper.java	0.00% <0.00%> (ø)