Add more information to the error message log

[glower]

• Add detailed information about the error to the error response

[codecov-io]

Codecov Report

Merging #236 into master will increase coverage by 0.14%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #236      +/-   ##
==========================================
+ Coverage   48.78%   48.93%   +0.14%     
==========================================
  Files          90       90              
  Lines        4747     4745       -2     
==========================================
+ Hits         2316     2322       +6     
+ Misses       2211     2206       -5     
+ Partials      220      217       -3

Impacted Files	Coverage Δ
service/sign/handlers_sign.go	88.75% <100%> (ø)	⬆️
service/assertion/actions.go	86.9% <100%> (+5.72%)	⬆️
service/assertion/actions_user.go	73.61% <100%> (ø)	⬆️
service/pivot/handlers_pivot.go	82.56% <100%> (-0.16%)	⬇️
service/assertion/handlers_user.go	83.33% <0%> (+16.66%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update be762b1...592ef7e. Read the comment docs.

[glower]

This is a possible fix for #235
If this PR is OK I will migrate rest of the responses to have more information

[pedronis]

Generally snapd should do something semi-reasonable if error cases come as application/json with a "message" field. That seems to be the case here.

[pedronis]

because of the try FindModel and then otherwise on failure eagerly try GetSubstoreModel it seems - as it was already - this will always produce slightly odd error messages/responses, this isn't new but if the goal is making for more understandable errors for the brand user this might need a larger rethink

[glower]

OK, I will drop this PR and only put more info inside of the internal log. We can have a separate conversation about error responses.

[pedronis]

I would ask @cprov whether the change here is already enough of an improvement, he was the one having trouble debugging, before dropping them. For more clarity the issue here is how apiKey is checked implicitly in one case but not the other, I don't know the detail of the data model and other usages enough but in principle it would be better if the apiKey check was explicit/distinguishable unless we think leaking whether a model really exists or not is deemed a problem.

[glower]

Yes, I agree on that, but in this case, I just wanted to improve logging, not touching any business logic at all.