structure the errors returned from repc to bindings

[phritz]

we are suffering from lack of structured errors returned by repc:

• we currently check to see if the returned errorstring contains JSLogInfo in order to not log scarily on errors that can happen naturally, eg overlapping syncs
• aaron had to hack around the lack of erros to determine connectedness https://rocicorp.slack.com/archives/CMQQ9EDML/p1599783976068500?thread_ts=1599783742.066800&cid=CMQQ9EDML

Note this could be solved by bringing more regularity to our rpcs a la https://github.com/rocicorp/repc/issues/119#issuecomment-691306940

[phritz]

   // The error paths of beginSync and maybeEndSync need to be reworked.
      //
      // We want to distinguish between:
      // a) network requests failed -- we're offline basically
      // b) sync was aborted because one's already in progress
      // c) oh noes - something unexpected happened
      //
      // Right now, all of these come out as errors. We distinguish (b) with a
      // hacky string search. (a) and (c) are not distinguishable currently
      // because repc doesn't provide sufficient information, so we treat all
      // errors that aren't (b) as (a).

-- https://github.com/rocicorp/replicache-sdk-js/blob/6a056d87b724507acb466b3aa1b921e213dac657/src/replicache.ts#L248

[phritz]

Another signal we want in bindings is if the diffserver got a 401 from the data layer (so bindings can trigger app-level data layer re-auth).

[phritz]

Ick. A failed push is not fatal for beginsync and so the push status code is correctly returned in beginsyncresponse.syncinfo.batchpushinfo.httpstatuscode. However a failed pull is fatal for the sync and so it throws an error, eg PullFailed(FetchNotOk(400)). we also have to check for PullFailed(FetchNotOk(4\d\d)) in the js :(