Iss 132/decode single dml errors

[k-capehart]

• this decodes errors into SalesforceResult from InsertOne and UpsertOne
• before, SalesforceResult did not show any errors, and you had to decode it yourself

per the docs, if there is a successful response then it returns a json response with id, errors array, and success boolean.
if there is an error, it returns a json response of an array of errors.

fixes #132

this is weird, because the REST API for Single DMLs returns an error code if Salesforce returns a validation error, but not for the Collection APIs.

This is best demonstrated in screenshots from Postman.

Using the Single Insert, it returns a 400 response with the error.

Using the Collections Insert, it returns a 200 response with the error in the response.

This is a quirk of the API, so keeping it like this would be consistent with Salesforce, but not consistent across go-salesforce. If that makes sense.

Option 1:

• keep this consistent with Salesforce API and populate Errors when InsertOne or UpsertOne returns Salesforce errors

Option 2:

• keep this consistent across go-salesforce and only populate Errors if there are client errors, not Salesforce errors

I lean towards Option 1, because I think modifying how go-salesforce handles the API is outside the scope. It's just a wrapper.

[k-capehart]

@derekperkins thoughts on above?

[codecov]

Codecov Report

❌ Patch coverage is 78.78788% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.68%. Comparing base (38e7595) to head (ff90498).

Files with missing lines	Patch %	Lines
dml.go	76.66%	5 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #134      +/-   ##
==========================================
+ Coverage   87.52%   87.68%   +0.15%     
==========================================
  Files           9        9              
  Lines        1643     1648       +5     
==========================================
+ Hits         1438     1445       +7     
+ Misses        115      114       -1     
+ Partials       90       89       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[derekperkins]

Returning errors in two places feels off to me. I think what I'd rather see is either:

• Unmarshaling []SalesforceErrorMessage succeeded, so don't return the reqErr, return nil for the error and only return the SalesforceResult
• Unmarshaling []SalesforceErrorMessage failed, so just return the reqErr

[k-capehart]

@derekperkins yeah I do see what you mean, but that's what I was getting at with the example in the PR description. For every other case, go-salesforce returns an error if the request code is a non 200. For these single DML operations, Salesforce returns an error code if the operation doesn't succeed, even if its for a Salesforce-y reason. So I feel the need to return it in both places if only to remain consistent with the API.

Part of the reason I've left this open so long is that I think its tricky and will probably be a technically breaking change. So it'll get lumped into that new major release I keep talking about.