abstract `rest_api` module into a seperate library

[2bndy5]

I've been pondering ways to reuse the rest_api module in other projects that want to post feedback in a CI workflow.

Abstracting the module into a standalone library would require trait implementations) allocated on the heap with polymorphic pointer (scoped to a wrapping struct) to keep cpp-linter algorithms separate from REST API usage. This mainly includes

• creating thread comments' content
• appending step summary content
• the comment marker prefixed to each comment (<!-- cpp linter action -->)
• creating file annotations (which could also be logged errors/warnings/notice/debug messages without specifying file info)
• creating PR reviews (and auto reuse or dismiss outdated reviews)
• get list of changed files for an event (and allow for fallback to git CLI for non-CI contexts)

Additional ideas

Create bindings for the abstracted library for use in python and/or node.js. Using rust async runtimes (like tokio) in python is not yet officially supported in pyo3 project (see pyo3 docs).

Update

This abstracted library shouldn't be specific to cpp-linter, so I have created the 2bndy5/git-bot-feedback library on my own GitHub account.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[2bndy5]

I started a project 2bndy5/git-bot-feedback which aims to resolve this. It doesn't have PR review support (yet). I might also create bindings to python and node.js in the future. For now, I'm just focused on abstracting the useful REST API implementations from here in a way that is agnostic of cpp-linter.

[2bndy5]

I'm ready to migrate to 2bndy5/git-bot-feedback for field testing (before I deploy from it main branch).

However, to ease migration, I'm focusing on addressing #83 first. There is some significant refactoring that needs to be done before adopting 2bndy5/git-bot-feedback.

[coderabbitai]

TLS reminder from PR #279

When abstracting the rest_api module (or replacing it with a wrapper around git-bot-feedback), please keep in mind the following TLS concern raised during PR #279:

The workspace reqwest dependency is configured with default-features = false and no TLS backend. The rest_api module is publicly exported from the library and requires reqwest::Client for HTTPS requests to the GitHub API. Currently, the bin feature enables reqwest/native-tls, but that feature also pulls in clap and colored, making it unsuitable for library consumers who only need REST API access.

When resolving this issue, consider one of the following:

• Add a dedicated tls (or similar) library feature that enables reqwest/native-tls independently of binary-only dependencies.
• Feature-gate rest_api behind that TLS feature so consumers must opt in.
• Or simply rely on git-bot-feedback handling its own TLS, which may naturally resolve this concern.

Posted as a reminder from PR #279, requested by @2bndy5.