fix(errors): add some more context to our 500 errors

[philbooth]

Related to #2884, but a speculative patch rather than a definitive fix for it.

As discussed in the FxA meeting a few weeks ago, sometimes our 500 errors are devoid of any context that would help identify the cause in Sentry. I know we talked about other Sentry options we can set and updating the npm dependency too, but I wondered whether just adding a bit more data to the error object would be a quick win to get us started regardless of those. Hence, this PR.

Of course, setting extra data on the error object means returning it through the API, so I only picked out 2 particular cases where I think nothing sensitive could leak out. I decided not to add an error message or stack trace to backendServiceFailure for instance, lest it reveal some inner implementation detail of our production environment.

The two errors that I did add data to are internalValidationError and unexpectedError:

• For internalValidationError I added op and data. The properties in data all originate from the request, so it seems like there's nothing bad that could leak out there.

• For unexpectedError I just added a bunch of properties from the request object so, again, the caller knows all of those by definition.

My hope is that next time either one of these shows up unexpected in Sentry, the extra context will help us understand what actually went wrong. Not sure what you guys think though, feel free to close if you think I'm barking up the wrong tree.

@mozilla/fxa-devs r?

[philbooth]

@vbudhram rightly pointed out in the meeting just now that request.app.geo is PII, so I've pulled that data out.

[philbooth]

In 811e584, I've addressed @vladikoff's point from the meeting about not sending PII from the request payload to Sentry.