fix: avoid performance degradation with Github and --hide-prev-plan-comments enabled

[oleg-glushak]

what

Switch from GitHub REST API to GitHub GraphQL for listing comments to expose the isMinimized attribute to avoid minimizing already minimized comments on each Atlantis command execution.

why

This helps to avoid performance degradation by minimizing only non-minimized Atlantis comments, as opposed to processing all comments sequentially on each Atlantis command execution.

tests

• I have tested my changes by running unit tests.
• I have tested my changes by running this version of Atlantis and checking if the --hide-prev-plan-comments performance still works in general and the performance degradation disappears.

references

Closes #5232

[X-Guardian]

Thanks for this @oleg-glushak. Can you check the linting error: https://github.com/runatlantis/atlantis/pull/5241/files#annotation_30986616047

[oleg-glushak]

Thanks @X-Guardian

The pull requests is ready for review again.

[X-Guardian]

I'm not keen on just ignoring the linter with a generic message. Can you investigate further? Also, can you try and avoid force pushing changes to the branch if you can, as this loses the links to previous check runs.

[oleg-glushak]

I'm not keen on just ignoring the linter with a generic message. Can you investigate further? Also, can you try and avoid force pushing changes to the branch if you can, as this loses the links to previous check runs.

Thanks for your feedback @X-Guardian . The same approach was used in a pull request merged last month: here. As far as I understand we either have to ignore this warning or switch from int to int32 in many places including the interface here which would make the scope of these changes much bigger.

Please let me know, if you have a strong opinion which way I should follow or if I understand something wrong.

[oleg-glushak]

@X-Guardian @jamengual I'd be happy to invest more time to push the pull request forward. Just let me know, if you have a strong opinion, if we need to do further work here.

[X-Guardian]

I'm not keen on just ignoring the linter with a generic message. Can you investigate further? Also, can you try and avoid force pushing changes to the branch if you can, as this loses the links to previous check runs.

Thanks for your feedback @X-Guardian . The same approach was used in a pull request merged last month: here. As far as I understand we either have to ignore this warning or switch from int to int32 in many places including the interface here which would make the scope of these changes much bigger.

Please let me know, if you have a strong opinion which way I should follow or if I understand something wrong.

Can you use the same lint annotation as the previous PR then and add a TODO comment to the client.go file.

[oleg-glushak]

@X-Guardian Done. The pull request is ready for review.