fix: do NOT convert errors to strings but keep the type

[crepererum]

Which issue does this PR close?

Closes #4434.

Rationale for this change

Now that DF emits ResourceExhausted errors for out-of-memory situations, it would be nice if the API user could somehow detect this situation (e.g. to convert this to a suitable HTTP status code).

What changes are included in this PR?

Convert a bunch of Execution errors into typed errors.

Are these changes tested?

⚠️ Consensus required prior to merging ⚠️

None. I'm not really sure how we want to prevent regressions here. It's just too many errors. I somewhat check-able rule (via some regex script?!) would be: "no Execution\(.+\.to_string". Shall I add this to the lint CI workflow?

Are there any user-facing changes?

Errors types slightly changed. This also changes error texts a bit.

[alamb]

Thank you @crepererum -- this is a nice cleanup 🧹 I think this PR is ready to go in as it is an improvement and we can perhaps improve the testing situation going forward.

None. I'm not really sure how we want to prevent regressions here. It's just too many errors. I somewhat check-able rule (via some regex script?!) would be: "no Execution(.+.to_string". Shall I add this to the lint CI workflow?

In terms of testing this PR I think that removing the anti-pattern from the codebase will reduce its likelihood of reappearing

We can also reduce the liklihood by adding some more comments to DataFusionError explaining the right pattern to wrap other errors (e.g. use DataFusionError::External to wrap external errors)

I think any sort of CI test to try and avoid new such patterns sneaking in will be brittle at best.

The "right" longer term solution to this approach is more structured errors rather than just messages, but I am not sure the benefits of that approach justify the costs -- and in any event that discussion should be on a separate issue i think

[alamb]

I think this is ready for review -- @andygrove @Dandandan what do you think?

[alamb]

Since I think this is a non controversial change (make the errors more structured) I am merging it in now. If we want additional testing I think we can do so as a follow on PR

[ursabot]

Benchmark runs are scheduled for baseline = d9e58db and contender = ffe97e5. ffe97e5 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java