fix(3259): Support deserialization of Locales created using BCP 47 format

[praneethjreddy]

Fix to support deserialization of Locales created using BCP 47 format

Issue: #3259

[praneethjreddy]

@cowtowncoder , Can you take a look at the PR and let me know if any changes needed

[cowtowncoder]

Thank you @praneethjreddy! I hope to review this soon, hopefully tomorrow.

Aside from reviewing, assuming all goes well one thing I'd need before merging is filled CLA from here:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

This only needs to be done once; the usual way is to print it, fill & sign, scan/photo, email to info at fasterxml dot com.
Once this is received I can merge the PR (and any future ones you may submit as well!).

Thank you in advance; looking forward to getting this merged and include in 2.13.0!

[cowtowncoder]

Is this separator/marker documented somewhere? Would be great to have a link to explanation.

[praneethjreddy]

https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#toString()

[cowtowncoder]

Looks good: all I need now is the CLA!

[praneethjreddy]

Sounds good. I will email CLA today

[cowtowncoder]

CLA received, can proceed when I have time to do the final review, merge.

[cowtowncoder]

Merged for 2.13, where things are fine. But with 3.0 (master) we'll run into issue due to fix #1600...
Serialization of Locale in 3.0 works as:

                Locale loc = (Locale) value;
                if (loc == Locale.ROOT) {
                    str = "";
                } else {
                    str = loc.toLanguageTag();
                }

instead of relying on Locale.toString().

Not sure what to do about this...

[cowtowncoder]

@praneethjreddy I was wondering if you might be able to help here, wrt 3.0. Tests are failing, but I am not yet sure if it is false positive (verification assumes old serialization), or if deserialization for 3.0 needs to account for possible variations.
3.0 can be built from master branch (default branch is 2.13, currently).

[praneethjreddy]

@cowtowncoder I can take a look. My suggestion is to use fromLanguageTag for deserialization in 3.0 since we are moving away from toString to toLanguageTag for serialization

[cowtowncoder]

Thank you @praneethjreddy I can try that when I get a chance, to see if just doing that would get past the issues.