Note this branch is based off the branch for #69, so if you want to review both commits in this PR that's cool, or if it's easier to review them separately I can wait until that one is merged and then rebase this against (rebased now)master.
Anyway, this is another step on the road to fixing #38. (I guess just the middleware is left after this?)
It updates the validation errors in src/web/extractors.rs to map to ApiError. In addition to mapping the error types, it also meant bringing across the status code and serialization stuff, hence ApiError has grown a status property and there are some implementations of Serialize introduced to make sure we return all the error details.
Additionally, because a couple of the db errors seemed like 400s rather than 500s, DbError has also grown its own status property to model that duality. I'm not sure, is that a layering violation, or is it okay for the db layer to know that some of its errors translate to 400s at the API boundary? I'm happy to do something different for this if you have suggestions.
The other contentious part of these changes is that the validation errors aren't strictly uniform. Some of them go through WithLocation and some of them are just custom error strings like the DbError and HawkError cases. This is purely a result of how I progressed through the module, I tackled the WithLocation stuff last and had already done the others. If it's important for them all to use the same structure, I can go back in and change them, no worries.