refactor: using slices.Contains to simplify the code

[dashangcun]

Description

Closes: #7837

This is a new function added in the go1.21 standard library, which can make the code more concise and easy to read.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against the correct branch (see CONTRIBUTING.md).
• Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
• Code follows the module structure standards and Go style guide.
• Wrote unit and integration tests.
• Updated relevant documentation (docs/).
• Added relevant godoc comments.
• Provide a conventional commit message to follow the repository standards.
• Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
• Re-reviewed Files changed in the GitHub PR explorer.
• Review SonarCloud Report in the comment section below once CI passes.

[gjermundgaraba]

Hi @dashangcun, thank you for the PR. Going forward, we will close PRs that do not have any issues attached to them. This is to be able to discuss and talk about solutions before people spend time on PRs, which have been a drain of time for both contributors and the team.

I am not apposed to replacing usages like this, but I would want to have an issue, and would likely want to make sure we replace this everywhere to ensure consistency.

For the time being I will close this issue, but feel free to open and issue where we can discuss and I can assign you to that :)

[dashangcun]

Hi @dashangcun, thank you for the PR. Going forward, we will close PRs that do not have any issues attached to them. This is to be able to discuss and talk about solutions before people spend time on PRs, which have been a drain of time for both contributors and the team.

I am not apposed to replacing usages like this, but I would want to have an issue, and would likely want to make sure we replace this everywhere to ensure consistency.

For the time being I will close this issue, but feel free to open and issue where we can discuss and I can assign you to that :)

OK, thanks for your guidance.

I will raise an issue first, and after the maintainer discusses and agrees, I will submit the corresponding PR.

[dashangcun]

Hi @dashangcun, thank you for the PR. Going forward, we will close PRs that do not have any issues attached to them. This is to be able to discuss and talk about solutions before people spend time on PRs, which have been a drain of time for both contributors and the team.

I am not apposed to replacing usages like this, but I would want to have an issue, and would likely want to make sure we replace this everywhere to ensure consistency.

For the time being I will close this issue, but feel free to open and issue where we can discuss and I can assign you to that :)

I just submitted an issue, thank you for your guidance. #7837

[gjermundgaraba]

@dashangcun can you look at the linter issue and fix that?

[dashangcun]

@dashangcun can you look at the linter issue and fix that?

gci behaves very strangely. Even with the previous import order (which complies with the go specification), I will not throw an exception locally.

Please approve ci, and I will track its execution results

[gjermundgaraba]

gci behaves very strangely. Even with the previous import order (which complies with the go specification), I will not throw an exception locally.

You need to run it with the config that is in the main folder. An easy way to run the linter on the whole project is to just run make lint

[dashangcun]

gci behaves very strangely. Even with the previous import order (which complies with the go specification), I will not throw an exception locally.

You need to run it with the config that is in the main folder. An easy way to run the linter on the whole project is to just run make lint

Modified, this time it should be able to pass lint detection.

Currently make lint takes up a lot of memory (over 50G), and it seems that lint problems in existing code will not be corrected.

I will study it further later and submit a new PR if necessary.

Thanks.

[gjermundgaraba]

Currently make lint takes up a lot of memory (over 50G), and it seems that lint problems in existing code will not be corrected.

I've had that problem with older versions of golangci-lint. Make sure you use 1.62 or higher.

[dashangcun]

Currently make lint takes up a lot of memory (over 50G), and it seems that lint problems in existing code will not be corrected.

I've had that problem with older versions of golangci-lint. Make sure you use 1.62 or higher.

Currently make lint takes up a lot of memory (over 50G), and it seems that lint problems in existing code will not be corrected.

I've had that problem with older versions of golangci-lint. Make sure you use 1.62 or higher.

I saw a failure in e2e-fork (TestChannelUpgrade_WithFeeMiddleware_Succeeds, TestTransferChannelUpgradesTestSuite), but it seems unrelated to this modification.

[gjermundgaraba]

I saw a failure in e2e-fork (TestChannelUpgrade_WithFeeMiddleware_Succeeds, TestTransferChannelUpgradesTestSuite), but it seems unrelated to this modification.

Yes, that one is a bit flaky. I will re-run and check again. I think this should be fine now, but will let you know.

[dashangcun]

Yes, that one is a bit flaky. I will re-run and check again. I think this should be fine now, but will let you know.

Okay. Thanks for your guidance!

[gjermundgaraba]

Thanks for the PR (and the patience) @dashangcun :)