Expose NetworkErrorException when request fails due to networking

[lbalmaceda]

Changes

Currently, all network requests performed by OkHttp will either fail or succeed.

• When they succeed, onSuccess is called and the requests have an HTTP status code set (e.g. 200, 401, 500, etc).
• When they fail, onFailure is called with an IOException instance. This scenario means network error (e.g. invalid host, timeout, etc).

Normally one doesn't need to capture this scenario as OkHttp is known for retrying the request a few times before reporting it as a failure. And additionally the Android SDK provides methods to check for connectivity before you perform a request. But in case you want a more granular control, this PR ensures that the exception is not treated as "another Auth0 error" along with the API errors (success branch above ☝️) and now has its own dedicated exception thrown. (I don't really like the idea of adding a new exception class, but here we go..)

Now users after calling request.execute() or request.start({callback}) can capture that Auth0Exception and ask if it's an instance of NetworkErrorException class by using the helper method isNetworkError().

//request.execute() throws "error"
if (error.isNetworkError()){
  //handle network error differently 
}

References

Closes #234.

Testing

• This change adds unit test coverage

• This change adds integration test coverage

• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines

• I have read the Auth0 Code of Conduct

• All existing and new tests complete without errors

[joshcanhelp]

@lbalmaceda - Would this cause any breaking changes for folks that are already catching the Auth0 exception?

(I don't really like the idea of adding a new exception class, but here we go..)

Seems funny to call this out in the description ...

[lbalmaceda]

@joshcanhelp Normally a few exceptions per project should be enough but I couldn't come up with another approach that didn't require me to create a new class. Because this is a different use case, I don't want to re-use the already generic enough class "Auth0Exception" for this scenario.

The callback receives the same exception type, an Auth0Exception. Internally, the "cause" of this exception changes from IOException to NetworkErrorException. This must be done this way because the IOException is also thrown in the scenario where the JSON parse step of a successful request fails. The only way to distinguish both scenarios is by changing the cause of the error in one of them.

This is fine. The code on those checking for the exception's cause will still compile and now they have the chance to check for this separate scenario.

[lbalmaceda]

@joshcanhelp ended up adding that helper method that at first I decided not to. This should make things even simpler to users.