Added clippy ignore rules for all errors and warnings

[Mirebella]

As mentioned #3223 (comment) and #3223 (comment), this PR adds a list of ignored(allowed) clippy errors and warnings to the CI checks.

[codecov]

Codecov Report

Attention: Patch coverage is 82.50000% with 7 lines in your changes missing coverage. Please review.

Project coverage is 89.80%. Comparing base (5e62df7) to head (0d71a5f).
Report is 18 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/util/indexed_map.rs	0.00%	1 Missing and 1 partial ⚠️
lightning-rapid-gossip-sync/src/processing.rs	0.00%	1 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️
lightning/src/ln/channelmanager.rs	50.00%	1 Missing ⚠️
lightning/src/routing/scoring.rs	0.00%	1 Missing ⚠️
lightning/src/util/logger.rs	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3238      +/-   ##
==========================================
- Coverage   89.82%   89.80%   -0.02%     
==========================================
  Files         126      126              
  Lines      103024   103020       -4     
  Branches   103024   103020       -4     
==========================================
- Hits        92543    92519      -24     
- Misses       7769     7776       +7     
- Partials     2712     2725      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TheBlueMatt]

Thanks, are there any of these that we're only hitting one or five times that we should just go ahead and fix immediately rather than allowing first?

[dunxen]

Here is a small sample of lints that seems to be low hanging fruit and can possibly be fixed in this PR:

• clippy::assign_op_pattern
• clippy::assigning_clones
• clippy::bind_instead_of_map
• clippy::bool_comparison
• clippy::wrong_self_convention
• clippy::while_let_on_iterator
• clippy::vec_init_then_push
• clippy::useless_format
• clippy::unwrap_or_default

A commit per lint fix would be a nice separation of concerns but combining a few small ones in a single commit should also be ok :)

[Mirebella]

I addressed all comments above. Ready for another review.

[vincenzopalazzo]

LGTM overall, just a though is if we need to have some sort of githook now to run what the CI is running.

I think it is a waste of CI cycles just pushing the code and find out that there is some warning to be fixed

[dunxen]

LGTM overall, just a though is if we need to have some sort of githook now to run what the CI is running.

I think it is a waste of CI cycles just pushing the code and find out that there is some warning to be fixed

There are no custom githooks at the moment, so that would be a whole other discussion on what would/wouldn't belong there. I'd recommend opening a separate issue.

[dunxen]

Thanks! I think it's okay to tackle the rest in some follow-up PRs. I'm sure there are many easy wins still remaining out of these allowed warnings but I haven't checked.

[TheBlueMatt]

I generally find the use of default strictly less readable than explicit Vec::new (which is ~free, though we can always do unwrap_or_else(Vec::new) to avoid the call), but for now its fine.