Fix GsonBuilder.setDateFormat ignoring partial DEFAULT; deprecate setDateFormat(int)

[Marcono1234]

Purpose

Resolves #1529

Description

The main issue was this line:

gson/gson/src/main/java/com/google/gson/GsonBuilder.java

Line 919 in 3b1b361

} else if (dateStyle != DateFormat.DEFAULT && timeStyle != DateFormat.DEFAULT) {

When one style was non-DEFAULT but the other was DEFAULT (e.g. dateStyle=SHORT, timeStyle=DEFAULT), then GsonBuilder would ignore the styles and use DEFAULT, DEFAULT. That is incorrect because it leads to a different date pattern.
This affected both setDateFormat(int) and setDateFormat(int, int) of GsonBuilder.

However, setDateFormat(int) is a bit counterintuitive: Since it only takes a 'date style' you would expect it to use DateFormat.getDateInstance. However, that is not actually the case, it uses DateFormat.getDateTimeInstance with the 'time style' being the value which has been set previously with GsonBuilder.setDateFormat(int, int). See also #1529 (comment) for more details.

Arguably this could have been fixed by changing setDateFormat(int) to use DateFormat.getDateInstance, as one would expect. But since we don't encourage users to use the locale specific formatted dates anymore (see e.g. #2546 (review)) I thought it would be easier to just deprecate the method, especially since it was not working properly anyway due to #1529 (which is fixed by this PR now though).

This pull request also removes internal code which handled the 'date style'-only case, but which was never actually called from the main code but only from tests.

Checklist

• New code follows the Google Java Style Guide
  This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.
  Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
• If necessary, new public API validates arguments, for example rejects null
• New public API has Javadoc
  • Javadoc uses @since $next-version$
    ($next-version$ is a special placeholder which is automatically replaced during release)
• If necessary, new unit tests have been added
  • Assertions in unit tests use Truth, see existing tests
  • No JUnit 3 features are used (such as extending class TestCase)
  • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
• mvn clean verify javadoc:jar passes without errors

[eamonnmcmanus]

I ran this against all of Google's internal tests and there were no failures.