Add id, classification to the software license policy json entity

What does this MR do?

This change adds the software license policy id and classification to the software license policy JSON entity. It combines the existing software license policies defined on the project with the latest software license scan report from the default branch.

The schema for the JSON response is approximately:

Before:

{
  "report": {
    "status": "ok",
    "job_path": "/root/security-reports/builds/933",
    "generated_at": "2019-10-09T21:31:51.599Z"
  },
  "licenses": [
    {
      "name": "BSD",
      "url": "http://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_.28original_.22BSD_License.22.29",
      "components": [
        {
          "name": "Django",
          "blob_path": null
        }
      ]
    }
  ]
}

After:

{
  "report": {
    "status": "ok",
    "job_path": "/root/security-reports/builds/933",
    "generated_at": "2019-10-09T21:31:51.599Z"
  },
  "licenses": [
    {
      "id": null,
      "name": "BSD",
      "url": "http://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_.28original_.22BSD_License.22.29",
      "spdx_identifier": null,
      "classification": "unclassified",
      "components": [
        {
          "name": "Django",
          "blob_path": null
        }
      ]
    }
  ]
}

Before this change the list of licenses displayed only included the licenses detected from the most recent license scan report for the default branch. This meant that we did not show the policies for software licenses that were configured for the project but not detected in the most recent report. We also could not provide the classification for each software license detected in the most recent report or provide the identifier for an existing software license policy to update if a user wishes to re-classify a software license policy.

A unique software license entry will appear in the JSON response for each license detected in the most recent license scan job that was run against the default branch combined with the software license policies configured for the project.

When a software license is detected in the project that does not have a policy it will have a null id and a classification of unclassified. Software licenses that are detected in the most recent license scan job, that also have a corresponding software license policy, will have an id that uniquely identifies the software license policy record for future updates i.e. change the classification.

The policies tab can render any software license policies that has a valid id attribute. The main license list page can render the full list of software license policies. As per the screenshots here.

Example JSON response:

To fetch the latest list of software license policies you can issue a GET request to https://gitlab.test/*namespace/:project_id/security/licenses.json endpoint.

$ curl -s http://gitlab.test:3000/root/my-project/security/licenses.json
{
  "report": {
    "status": "ok",
    "job_path": "/root/my-project/builds/933",
    "generated_at": "2019-10-09T21:31:51.599Z"
  },
  "licenses": [
    {
      "id": 1,
      "name": "Custom",
      "url": "",
      "spdx_identifier": null,
      "classification": "blacklisted",
      "components": [
        {
          "name": "jive",
          "blob_path": null
        }
      ]
    },
    {
      "id": null,
      "name": "Julien Fache",
      "url": null,
      "spdx_identifier": null,
      "classification": "unclassified",
      "components": [
        {
          "name": "mots-vides",
          "blob_path": null
        }
      ]
    },
    {
      "id": null,
      "name": "MIT License",
      "url": "http://opensource.org/licenses/mit-license",
      "spdx_identifier": "MIT",
      "classification": "approved",
      "components": [
        {
          "name": "rails",
          "blob_path": null
        }
      ]
    }
  ]
}

#34824 (closed)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team