Clarify EnvironmentService handling of invalid xhAppTimeZone config

[minusleaf]

Fixes the issue where the log would never call because configZoneId given a bad xhAppTimeZone value would return the defaultZone. This would then be considered valid as an available ID by the conditional and therefore not log if we use the default or not.

[amcclain]

It's OK (and good) to remove this default here, but note that's only because we always ensure that the xhAppTimeZone config is created - that happens in Bootstrap.groovy. Before we had that code, this second arg was important as otherwise configService would throw if the config was not found in the DB.

Given the bootstrap routine, we know the config will always be there, but we now are defending against it being some unexpected/unknown zone.

As we discussed (and for the record here), TimeZone.getTimeZone('someBadZoneString') actually does default to GMT, which is functionally the same as UTC although not identical in Java world (different actual TimeZone objects, same offset).

So the code we had before would work, but it was a bit odd and did not get you exactly what it promised, so I'm still happy to have our improvement here.

[amcclain]

This isn't quite correct - we were always printing that error log, the code now is just a bit more explicit and exact in terms of how it is falling back to the default.

But TBH I don't think we need a CL entry here - this is a very minor code cleanup, not really a bug, and no functional difference. Pls remove it and then happy to merge. Thanks!