Subclass Error to handle Server and Client errors

[shanecav84]

Closes #61

[coveralls]

Coverage decreased (-0.2%) to 96.617% when pulling c76681d on patientdev:master into dfff964 on dashofcode:master.

[shanecav84]

I wasn't able to figure out how to simulate 4xx and 5xx errors for testing (without using VCR).

[coveralls]

Coverage decreased (-0.7%) to 96.087% when pulling fa9e848 on patientdev:master into dfff964 on dashofcode:master.

[coveralls]

Coverage decreased (-0.7%) to 96.087% when pulling 918dadb on patientdev:master into dfff964 on dashofcode:master.

[coveralls]

Coverage decreased (-0.7%) to 96.087% when pulling d27dce4 on patientdev:master into dfff964 on dashofcode:master.

[shanecav84]

tracker_api rescues Faraday::Error::ClientErrors, which is raised when a response returns an HTTP status code in the range 400...600 (see Faraday::Response::RaiseError). tracker_api then raises its own TrackerApi::Error.

This PR subclasses TrackerApi::Error into ClientError for 4xx status codes and ServerError for 5xx status codes, allowing users of tracker_api to handle these errors separately without having to implement the logic themselves.

[coveralls]

Coverage decreased (-0.7%) to 96.087% when pulling 73595d1 on patientdev:master into dfff964 on dashofcode:master.

[coveralls]

Coverage decreased (-0.06%) to 96.754% when pulling b68f84f on patientdev:master into dfff964 on dashofcode:master.

[shanecav84]

Finally figured out how to mock the Faraday error we're rescuing without using VCR. The tests add assertions for all status codes for the range 400..599. Not sure if you are fine with assertions just for, say, 400 and 500.

[coveralls]

Coverage increased (+0.02%) to 96.834% when pulling 8488916 on patientdev:master into dfff964 on dashofcode:master.

[shanecav84]

*bump*

[forest]

Looks good. Sorry for the delay.

[shanecav84]

No problem. Thanks!