Save in progress/no auth.fix

[nihil2501]

Problem

There was a refactor to reuse a platform-wide function apiRequest within save-in-progress (SIP) actions. It looks like this caused a regression that lost those actions' ability to distinguish between different HTTP error codes and, in turn, the UI's ability to exhibit behavior tailored to the case of 401, the no-auth case.

Solution

This commit extracts an internal API request utility function that resolves with the response so that callers have access to data like the HTTP status code that they can more robustly interpret, as SIP expects to do. apiRequest then becomes a small wrapper around that and another small wrapper formApi is introduced to meet SIP's expectations.

Through our fix/refactor, we isolate all and only the erroneous behavior we were importing before and show the correct behavior after.

Before

response => {
  if (response.ok || response.status === 304) {
    if (isJson(response)) return response.json();
    return response;
  }

  if (isJson(response)) return response.json().then(v => Promise.reject(v));
  return Promise.reject(response);
}

After

response => {
  if (response.ok || response.status === 304) return response.json();
  return Promise.reject(response);
}

Each atomic step of the fix/refactor is captured in its own commit.

Steps

1. Reorder conditional work in apiRequest.
2. Extract response-preserving fn to facilitate SIP fix.
3. More appropriate location for form API URL helper.
4. Consolidate into a new form API helper.
5. Copy apiRequest implementation before introducing fix.
6. Reshape apiRequest & its copy before introducing fix.
7. Fix - only provide response as rejection value.
8. Comment on an existing deficiency of apiRequest.
9. Fix - reflect that form API client has a JSON backend.