Add trace log for HTTP error responses

[optionsome]

Summary

Removes OtpHttpClient's own logger and passes in loggers from where it's used from. Adds a trace log for http responses in case there is an error response coming from an external API.

Issue

closes #5761

Unit tests

New tests will not be added.

Documentation

Not needed

Changelog

Not sure if needed

[abyrd]

Discussed in today's meeting: it's not clear how to proceed. The original concern that was voiced about logging here is that the HttpClient is a "framework class" that could be used in many different places throughout the project. Turning on trace-level logging could produce an overwhelming amount of messages that are not limited to the one usage site that one is trying to debug. The original implication was that framework-like classes should return enough information (or throw exceptions specific enough) so the caller can log errors in a more context-specific way. There were some reasons why this didn't work in this particular case: it would result in too much boilerplate logging calls and checked exception handling at every call site, and the return types would have to be overly complex or incur significant overhead for logging facilities that are rarely used. So the remaining solution was to pass the caller's logger into the framework's methods. However, this goes against most people's expectations when the loggers are assigned names that are the fully-qualified names of classes. We observed that it's common for Java library code (e.g. database or HTTP tooling) to emit its own debugging log messages using its own logger, and that the (sometimes surprisingly complex) Java logging world is apparently designed to work this way (each library calls a logging API which are all routed to the top level application's logging implementation). So what we are looking for is widespread Java conventions for debug and trace level logging within a library (or project-specific framework code) where logging messages can be filtered by call site or use case.

[optionsome]

I've now done refactoring based on last weeks discussion but there are few classes I'm still slightly unhappy with as I've explained in #5795 (comment) .

[codecov]

Codecov Report

Attention: Patch coverage is 54.38596% with 52 lines in your changes are missing coverage. Please review.

Project coverage is 67.86%. Comparing base (0bed0f2) to head (2edd276).
Report is 90 commits behind head on dev-2.x.

❗ Current head 2edd276 differs from pull request most recent head fd8b26c. Consider uploading reports for the commit fd8b26c to get more accurate results

Files	Patch %	Lines
...rg/opentripplanner/framework/io/OtpHttpClient.java	15.78%	16 Missing ⚠️
...ipplanner/framework/io/JsonDataListDownloader.java	12.50%	7 Missing ⚠️
...tripplanner/framework/io/OtpHttpClientFactory.java	82.50%	7 Missing ⚠️
...ehicleparking/hslpark/HslFacilitiesDownloader.java	28.57%	5 Missing ⚠️
.../ext/vehicleparking/hslpark/HslHubsDownloader.java	28.57%	5 Missing ⚠️
...irectory/VehicleRentalServiceDirectoryFetcher.java	0.00%	3 Missing ⚠️
...er/ext/siri/updater/SiriETGooglePubsubUpdater.java	0.00%	2 Missing ⚠️
...t/siri/updater/azure/AbstractAzureSiriUpdater.java	0.00%	2 Missing ⚠️
...ner/datastore/https/HttpsDataSourceRepository.java	33.33%	2 Missing ⚠️
...entripplanner/ext/siri/updater/SiriHttpLoader.java	0.00%	1 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##             dev-2.x    #5795   +/-   ##
==========================================
  Coverage      67.85%   67.86%           
- Complexity     16546    16562   +16     
==========================================
  Files           1906     1909    +3     
  Lines          72291    72388   +97     
  Branches        7444     7446    +2     
==========================================
+ Hits           49055    49128   +73     
- Misses         20716    20739   +23     
- Partials        2520     2521    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.