Use JsonUtil.getJsonObject in AbstractApiBean, MakeDataCountApi

[bencomp]

What this PR does / why we need it:
Rewrite methods to use JsonUtil.getJsonObject or JsonUtil.getJsonArray, so that try-with-resources for parsing JSON happens in the same way across the updated methods.

I added methods to JsonUtil that take an InputStream or a file name and return the data as JsonObject. The latter has a new name to prevent a clash of method signatures.

I also removed calls to deprecated Gson methods and then proceeded to remove Gson completely from JsonUtil. Pretty-printing a JSON string now uses the methods from JsonUtil itself. Their output is a little different, which meant I had to change expected outcomes in JsonUtilTest#testPrettyPrint.

Which issue(s) this PR closes:

Closes #10054
Closes #10056

Special notes for your reviewer:

Like before, JsonExceptions may still be thrown.
Since this is a RuntimeException, I only mention it in the Javadoc.

Suggestions on how to test this:
Please review the changes to JsonUtilTest and see that unit tests pass. Also run the API tests, please.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
No.

Is there a release notes update needed for this change?:
No.

Additional documentation:
n/a

[coveralls]

coverage: 20.006% (+0.006%) from 20.0% when pulling 785964d on bencomp:10054-10056-json-reader into 6b2bcfb on IQSS:develop.

[bencomp]

Ooh, all checks have passed! 🎉

[rtreacy]

I like what I'm seeing here, including refactoring out Gson dependencies. Was just talking about this with @pdurbin a couple of days ago. While this served a purpose when it was introduced into Dataverse, a lot of things like this can now be handled with well vetted standards that have been developed since then.

[bencomp]

@qqmyers I think I fixed it. The javadoc for getJsonObject(InputStream) now also mentions that callers are responsible for closing the InputStream.

[qqmyers]

Looks good!

[pdurbin]

This would be a good opportunity to see if we can add ProvIT to the API test suite.

@jp-tosca you can run in manually like this:

mvn test -Dtest=ProvIT

For me it's failing. I'm not sure why:

[ERROR] Failures: 
[ERROR]   ProvIT.testAddProvFile:147 1 expectation failed.
Expected status code <400> but was <403>.

[ERROR]   ProvIT.testFreeformDraftActions:77 1 expectation failed.
Expected status code <200> but was <403>.

Ideally we'd get this test working and add it to tests/integration-tests.txt in this PR so that Jenkins exercises it all the time.

Here's how to test manually, if we must: https://guides.dataverse.org/en/6.0/api/native-api.html#get-provenance-json-for-an-uploaded-file

We should also exercise getWrappedMessageWhenJson somehow. From a quick look downloading a file should hit it if the file can't be found but needs testing.

To check API test coverage of this PR, see https://jenkins.dataverse.org/job/IQSS-Dataverse-Develop-PR/job/PR-10062/4/execution/node/3/ws/target/coverage-it/index.html

You can see GetProvJsonCommand has zero coverage, for example: https://jenkins.dataverse.org/job/IQSS-Dataverse-Develop-PR/job/PR-10062/4/execution/node/3/ws/target/coverage-it/edu.harvard.iq.dataverse.engine.command.impl/index.html