Is your feature request related to a problem? Please describe.

The problem is that we often refetch (and re-apply) the same data although it has not changed. This leads to increased load on the bandwidth and cpu load in the updater that is not needed.

Goal / high level use-case

The goal is to implement the strategy described her: MobilityData/gbfs#708

It's a low effort solution to the problem. Long term, ideally we would have a push-based solution instead, but this should also have real impact.

Describe the solution you'd like

The solution requires extending the OtpHttpClient to support getting the response headers together with the body. I suggest adding a new method that returns a wrapper object containing the response headers together with the deserialized body. THe method signature could be something like this:

<T> HttpResponseWithHeaders<T> getWithResponse(
    URI uri,
    Duration timeout,
    Map<String, String> headers,
    ResponseMapper<T> contentMapper
  )

where HttpResponseWithHeaders is the wrapper object that contains the statusCode, response headers and the body of type T.

The gbfs feed loader would then take care of keeping track of ETag values, sending them as part of the requests (as If-None-Match) and handling any 304 response.

Describe alternatives you've considered
Another possible solution is to build this support directly into the OtpHttpClient, but it still needs a way to signal to the caller that e.g. "null" or empty means not modified, or some kind of wrapper return type.

Yet another possibility is (a hybrid solution) to build a wrapper around the OtpHttpClient itself, which augments it with this functionality. That way other code could also benefit from this functionality - but we still need to modify the OtpHttpClient.

Personally, I think keeping this local to the updater is good enough for now.

Additional context
I already have a working POC locally with OTP working together with the corresponding change in lamassu: entur/lamassu#770