ci: Add workflow to run a FOSSA scan

[qmonnet]

Apparently the "Quick Import" feature from FOSSA is not good enough for Rust projects, and we need to run the FOSSA CLI tool, either ourselves or using the official GitHub Action. This commit introduces a new workflow that uses this Action to perform a scan on Pull Requests and on pushes to the main branch.

[qmonnet]

We need to figure out:

• Is there any useful info that we can leverage here from the report? The report is generated and published at the URL provided in the logs (although it's private and one needs to be logged in as a member of the team on FOSSA - we should probably make this project public, by the way).

• Does the Action fail loudly when we break things? When do we break things, exactly?

• I own the API token in use which means all reports are marked as sent by me, which probably doesn't matter. I haven't found another way to create an authentication for the CI.

[qmonnet]

Related: #332

[qmonnet]

Right now the scan is “failing”:

But the Action and workflow returns successfully 🙃, go figure. I haven't found a way to 1) fix the report and 2) make the workflow fail when the scan fails

[qmonnet]

The branch for scans on PRs is also marked as “master” in the interface, not sure why. Maybe that's the branch name created by the checkout action? Anyway, this means we probably don't have an easy way to identify which PR a given report comes from, in the FOSSA web interface.

[daniel-noland]

we should probably make this project public, by the way

??? dataplane is already public?

[qmonnet]

??? dataplane is already public?

Sorry I meant, in the FOSSA interface. If you click on the badge above, I'd expect you to get a 404.

[Frostman]

I've made it public

[qmonnet]

I think the issue in routing is a bug in FOSSA's tool. The file is not ours, looking at the author's name I think it considered https://crates.io/crates/routing instead of our own crate. Not sure of the best way to fix this: we could ignore this dependency, but I suppose would cause the tool to ignore any issue in our routing crate, which is also not what we want. We can also rename our own crate, but just for the sake of making the FOSSA CLI happy that sounds a bit silly.

As for the other two in dpdk-sys - they're interesting, are we allowed to ship these GPL/LGPL files even if they're only header definitions? I wouldn't bet on it. What alternative do we have? Recreating our own definition file?

[qmonnet]

Just updated the workflow to run on pushes to main only, given that it doesn't bring anything useful in the case of PRs.