Add cargo deny config and add cargo deny job to ci

[iamjpotts]

Add cargo deny configuration which matches status quo of the crate. Also add a job to CI to run the check.

This will cause CVEs, duplicate dependencies, unexpected licenses, and other issues to be caught during CI, before the crate is published.

[Stebalien]

Hm. So, the job is really slow because we have to compile it. Could you switch to downloading a pre-compiled binary from https://github.com/EmbarkStudios/cargo-deny/releases/tag/0.14.1?

[iamjpotts]

Hm. So, the job is really slow because we have to compile it. Could you switch to downloading a pre-compiled binary from https://github.com/EmbarkStudios/cargo-deny/releases/tag/0.14.1?

There's a github action referenced on that page, I'm going to try that first. The first commit with have two copies of the job, so I can inspect and compare their results and timings.

[iamjpotts]

It looks like the CI job is awaiting repo maintainer approval to run.

[Stebalien]

LGTM modulo the gitignore changes.

[iamjpotts]

Of the two flavors of github actions for cargo deny I added, which would you prefer to keep?

A) The flavor that uses a specific version of Rust, which we can maintain to match this crate's minimum rust version, and takes 3 minutes to run B) The flavor that uses whatever version of Rust is packaged with the Embark action, may be newer or older than this crate's minimum rust version, but only takes 30 seconds to run

A, or B? B, or A? (as the eye doctor would say)

[Stebalien]

Ah, I see. Keep the precompiled version. As far as I know, the rust version shouldn't matter much unless I start using a new cargo feature, at which point I can upgrade it.

[iamjpotts]

Got rid of the gitignore change, and consolidated the deny jobs to just the one using the pre-built binaries.

Workflow is pending approval again (probably due to it being edited).

[iamjpotts]

Ah, I see.

Pardon the pun :)

[Stebalien]

Thanks! And I swear the pun was unintended :)