Add clippy checks to continuous integration

[Luni-4]

Pull Request Template

Checklist

• Confirm that run-checks script has been executed.

Changes

This PR adds clippy checks on Linux directly on CI and uses actions to better show in PR clippy warnings. It updates #552

[Luni-4]

@antimora and @nathanielsimard I think I've finished, so this PR is read to be reviewed

[antimora]

If I understand correctly, the primary goal of this PR is to separate the clippy and formatting into individual jobs, much like we did with typos. If so, I'm on board with this idea. However, to maintain consistency and ease of maintenance, we should continue to execute these tasks within the run-checks script, as we've done with typos. This approach ensures that any changes to configuration or versions will be uniform. Using GitHub's clippy/formatting might lead to different outcomes compared to running the same script, which was the key reason for integrating the CI jobs with the script in the first place.

Should we need to improve the reporting of fmt/clippy outputs, the changes should be made within the script itself.

If we can agree on this, I've provided additional feedback on the implementation.

[Luni-4]

The goal of this PR consists of providing a way to better visualize clippy lints as annotations inside each PR without having to look for the problems within CI output. It's a PR oriented to help newcomers in detecting clippy lints in a simpler way since they are shown directly in their PRs. But if there is no agreement on this aspect, this PR does not make sense at all. Separating clippy and format for optimizations reasons is quite useless since they are not computational heavy at all. I had already described this part in #552

Providing a better clippy and format output directly in the script is just a waste of time, we can simply use the output provided by the two binaries in that case.

Personally I think CI should be superior than scripts because a CI is the last "judge" to evaluate a PR since:

• Anyone can see the outcome, so it's not important if a developer has run locally the scripts. We can catch the issues related to the considered PR immediately.
• You can have comments in it that helps you to fix some aspects such as code coverage or clippy lints annotations
• You cannot do some things locally with scripts without forcing a developer to set his/her own machine according to our specifications. CI allows a more degree of freedom.

But I also understand that an action can be quickly unmaintained and not conform to the new GitHub Actions APIs. So using only the necessary ones can be a valid point.

Unfortunately I do not see a tradeoff for this PR, we can leave as it is now and create a new PR for the INFRASTRUCTURE books.

[antimora]

I couldn't understand initially what better output you were telling us about. So I dug in briefly about this clippy action. It appears from my limited research this action uses clippy and forwards output (or formats) to reviewdog service (that is why it requires git hub token in the code), which actually talks to the originating PR via comments. So it's clippy + clippy-action + reviewdog.

Potentially we could enhance our PR workflow with the automated review tools like reviewdog, and I am open to this. I know little about current trend, so it'd be interesting to explore.

With this new information, I am not exact sure why you had to modify the current run-checks if you added action/clippy. Does the action take the output?

[Luni-4]

Waiting for upstream giraffate/clippy-action#82

[Luni-4]

@antimora

I have found another way to show clippy lints within PRs, which is simpler than before, so this PR is no more blocked

[Luni-4]

@antimora and @nathanielsimard

I rebased this PR on top of main