Allow to deserialize more valid RFC3339 date-time and make the format customizable

[andreaTP]

Description

Fix #5382

Given the fact that the specification allows for even more special cases (e.g. using lower-case 't' and 's'), here we propose to cover the most common formats with defaults, but we enable the users to customize (separately) the format for serialization and deserialization of date-time fields.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[andreaTP]

This is a leftover, not used around hence not a breaking change.

[andreaTP]

Ideally, this fix should be backported to a 6.8.1 release, cc. @manusa .

[fabiobrz]

HI @andreaTP - I've gone through the specification and checked the implementation changes, which LGTM. I dropped one very minor question about a potential formatting typo in the README, but approving anyway.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

51.1% Coverage
8.6% Duplication

The version of Java (11.0.20) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[andreaTP]

For the records:

• the original formatting was working fine on Java 17+ but it was failing on Java 8 ( 🤯 )
• I improved the DateTimeFormat patterns and found a cross-compatible encoding
• I added more negative tests to more accurately verify that the output is expected

all in all, I'm happy to make this configurable so that users will be able to tweak it depending on their environment/use-case.