Add Exception information to failed requests

[StefanCuypers]

Is your feature request related to a problem? Please describe.
See idea #375

Describe the solution you'd like
FailedRequests on PullResult now only returns the ServiceResponse. This is great to have failure reporting from the communication with the server, but it does not cover local problems (e.g. trying to write null to a non-nullable property).
It would be great if FailedRequests also returned Exception information on local problems to make troubleshooting easier.

Describe alternatives you've considered
None

Additional context

[adrianhall]

I'm not sure this is an actual problem right now. The PullOperationManager bubbles locally generated exceptions up to the calling method.

There are two internal queues - one for doing the actual network traffic - if there is an error here, it is added to the FailedRequests data set and we move onto the next request. The second (the databaseUpdateQueue) has no exception handling in it, so any errors in here will throw.

The problem here is that if we fail a database update, we want the rest of the update to fail; otherwise we get into a problematic state in the database that can only be cured by resetting the local database.

Happy for other ideas here, but it's just too easy to get into a bad state when an exception is thrown in the middle of the process and it isn't captured by your code.

[adrianhall]

Follow-up: Probably wontfix - if no update/suggestions by 7/31, I'm going to close this.

[StefanCuypers]

I got onto this because I had a local class with a non-nullable property, where the synch fetch tried to write null to it (on a deleted record).
The synch reported a failure, but the failedrequest did not have a ServiceResponse.
I was a bit lost and so I downloaded the source of the DataSync to debug it and found the cause in the Exception that was thrown but did not surface.

[adrianhall]

If you can provide the file and line number where the exception occurred, that would be helpful. Exceptions are meant to bubble up, so we have a corner case I likely have to deal with.

[StefanCuypers]

Its in the PullOperationManager line 187.
There is a catch of DatasyncPullException that adds the ServiceResponse to the failed requests.
But this ServiceResponse can be succesfull if the cause is not in the service response itself like when DatasyncPullException is thrown on line 244 or 255.
Another solution would be to throw another kind of Exception than a DatasyncPullException on line 244 and 255 and then it would indeed bubble up.

[adrianhall]

Let me take a look this week; I'll see what I can do to ensure it is bubbled up.