Replace usages of org.json with Jackson

[nscuro]

Description

In cases where we don't directly map JSON to and from POJOs, we currently predominantly use org.json:json.

That library once shipped with Unirest, but Unirest switched to another serialization library, and we have moved away from Unirest recently, too.

This PR replaces usages of org.json with Jackson.

Addressed Issue

Closes #1113

Additional Details

Another option would've been to use JSON-P, but the spec and its implementations lack capabilities of object mapping. That is, it's not possible to put a POJO into a JSON object using the JSON-P API. Jackson supports this.

A new utility class, org.dependencytrack.common.Json, has been added which includes various methods (e.g. optString, optArray etc.) that behave just like their counterparts in org.json. This was done to reduce the amount of necessary refactoring to a minimum.

Tests for various existing JSON transformations (e.g. the FPF) have been added along the way, to ensure that this change does not introduce regressions.

Usage of the org.json.* package has been blacklisted with Checkstyle.

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[walterdeboer]

@nscuro Let's get this out of the way :-) nscuro#187

[nscuro]

Thanks @walterdeboer! I did put this on hold because there are (were?) still pending PRs that utilize org.json, and I wanted to avoid forcing contributors to rebase their PRs 😅

Greatly appreciate the work, that'll certainly speed things up!

[walterdeboer]

I'm one of the pending PR's, that's why I wanted to give it a push :-)

[sonatype-lift]

🛠 Lift Auto-fix

Some of the Lift findings in this PR can be automatically fixed. You can download and apply these changes in your local project directory of your branch to review the suggestions before committing.¹

# Download the patch
curl https://lift.sonatype.com/api/patch/github.com/DependencyTrack/dependency-track/2520.diff -o lift-autofixes.diff

# Apply the patch with git
git apply lift-autofixes.diff

# Review the changes
git diff

Want it all in a single command? Open a terminal in your project's directory and copy and paste the following command:

curl https://lift.sonatype.com/api/patch/github.com/DependencyTrack/dependency-track/2520.diff | git apply

Once you're satisfied, commit and push your changes in your project.

Footnotes

1. You can preview the patch by opening the patch URL in the browser. ↩

[walterdeboer]

@nscuro And some sonatype-lift fixes here: nscuro#188 (rebased)

[melba-lopez]

@nscuro curious question. Lately i've seen NVD "being re-evaluated" or not evaluated at all. Ive noticed some wonkiness with some tools (not sure i've seen it in DT), where it doesn't seem to like that status. Do we defer to another alias (if they are on) for the scoring if NVD has not evaluated it??

[nscuro]

Are you asking in general, or specific for Snyk?

Generally we do not re-use scoring of aliasing vulnerabilities, if a given vuln does not have a scoring.

For Snyk specifically, they provide at least one score for each vulnerability. Beside Snyk's own scoring, and the "offical" NVD one, there is also vendor-specific scoring from Red Hat, SUSE, etc.; In that case DT should follow a priority list of sorts, where it would fall back to the next preferred source if necessary.

[melba-lopez]

yes thats what i was thinking. following a sequence of logic if there happens to be a vuln that does not have a score (for some reason) to default to the next best source.

[nscuro]

Moved to 4.10 as we want this to be thoroughly exercised in users' test environments. Merging shortly before 4.9 release is too risky.