Handle API errors appropriately

[incognitojam]

The fetcher tries to parse JSON error responses from the server, but this schema isn't really defined anywhere and I'm not sure it's even consistent across all endpoints.

We should instead retry requests where we can, and pass error information back to the caller in a structured way. We can use the status code to detect things which we can handle:

Server Errors

• 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout - retry with backoff?
• everything else just tell the caller there was a server error

Client Errors

• 401 Unauthorized - we could redirect the user to login when this happens
• 403 Forbidden - e.g. this happens when listing routes, but it would be good to differentiate between "this device has no routes" and "you don't have permission to view this" instead of bailing with an empty array 🙂
• 404 Not Found - we can know for sure that this device/route is not available, we should pass this information back to the caller
• anything else might be due to a bug (e.g. bad request, method not found)

Requirements:

• Detect errors for the common cases listed above
• Provide structured information to the caller when there is an error to be able to choose the correct action (signing out, showing error message, showing fallback)
• Remove .catch(() => undefined) as a default on every API function

[sshane]

Let's add handling/messages before we add retries. I don't want to silently mask bugs/inefficiencies for a while.