Makefile: changed Rust lint clippy to the one included in SDK

[mjsterckx]

Issue number:

Closes #2704

Description of changes:

Changed the clippy used in the check-clippy target for Rust linting to the one included in the BUILDSYS_SDK to avoid conflicting lints between local builds and GitHub actions. Blocked until bottlerocket-os/bottlerocket-sdk#89 is merged and included in an SDK update.

Testing done:

Ran cargo make check-clippy with a local cargo install which resulted in a few warnings/errors. Ran it again with the SDK version of clippy which finished with no problems and exit code 0.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[jpculp]

I'm not sure how often it would actually get used, but do we want to add an override based on an environment variable to use the local clippy? It might be nice for developers that want to ensure this workflow will pass with a newer toolchain than the SDK provides.

[mjsterckx]

I personally don't think it would get used enough to warrant an override. Developers who want to check their syntax with a newer toolchain can just run cargo clippy. @bcressey @webern any thoughts?

[webern]

I personally don't think it would get used enough to warrant an override. Developers who want to check their syntax with a newer toolchain can just run cargo clippy. @bcressey @webern any thoughts?

I tend to agree. I think it's easy enough to go into the sources or tools directory and run cargo clippy by hand rather than using an override. (That's what I would probably do...)

[bcressey]

Doesn't have to happen in this PR, but do we also want to give cargo fmt the same treatment, in case the behavior changes across versions?

[mjsterckx]

Doesn't have to happen in this PR, but do we also want to give cargo fmt the same treatment, in case the behavior changes across versions?

I'm not sure how frequently the behavior changes, but I like the idea of staying consistent. It should be an easy addition, so I can create an issue for that and work on it in a different PR.