After SKARA-2182 I have realized that we do have some GET calls where an empty response isn't necessarily an error. HostedRepository::fileContents is one example. In that case we would be better off looking at response codes. I don't think we have a usecase currently where we need to retrieve an empty file, so we should be fine for the short term, but I don't want to leave us in that situation.

To better remedy this, I think we need to have RestRequest treat more response codes as errors by default and also expose a more flexible way for callers to decide which codes should result in what. We then need to go through every caller and make sure they actually do handle possible responses in a good way. There are at least 3 possible responses we need to consider:

1. Success, the expected data was retrieved and returned
2. Bad but expected data was received, like a 404 when checking if a user exists. This needs to be communicated with the caller to take appropriate action, which could be an error response to the user.
3. Some kind of server error prevented us from receiving the expected data. This should most likely result in a RestException to get the WorkItem to terminate and be retried automatically.

Today we aren't identifying situation 2 enough, and instead letting them resolve as 3, which causes infinite loops of retries.

The current API for telling a RestRequest how to handle response codes, by supplying an error transformer, only applies to codes >=400. We need to include at least 300 as well, but likely anything but 200 by default, or possibly a different set of defaults depending on the http methods. We could have a set of configurable "success" codes in addition to the error transformer and call the transformer for anything not in that set.

Ultimately, this should replace what was done in SKARA-2182.