Story (Required)

As a GitLab repository maintainer, when I'm reviewing a Merge Request, I want to be able to approve tests by commenting `/ok-to-test` in a reply to a discussion thread, not just in a top-level comment.
As a Pipelines-as-Code administrator, I want the GitLab provider to cache user permission checks to improve performance and reduce the number of API calls.

This feature improves the user experience for maintainers engaging in conversations on a Merge Request, allowing them to approve tests more naturally within a discussion. It also enhances system performance by avoiding redundant API calls to check for user membership, making the process faster and more efficient.

Background (Required)

Previously, the GitLab provider would only scan the top-level note in a Merge Request discussion for commands like `/ok-to-test`. This meant that if a maintainer replied within a thread, the command would be ignored. This was inconvenient and forced an unnatural workflow.

Additionally, the provider would perform a GitLab API call to check for project membership for every single comment it evaluated. In a Merge Request with many comments, this led to a high number of redundant API calls, slowing down the process and potentially hitting API rate limits.

This change addresses both issues by scanning all notes within a discussion thread and introducing an in-memory cache for membership checks.

Out of scope

This story does not introduce a persistent, cross-request cache (e.g., Redis). The cache is in-memory and its lifecycle is tied to the provider instance handling the event.
This change only affects the GitLab provider; other SCM providers are not impacted.

Approach (Required)

Dependencies

None.

Acceptance Criteria (Mandatory)

• Given a Merge Request is opened by a user who is not a member of the project.
• When a project member comments on the MR (e.g., "Looks good, but can you fix the typo?").
• And another (or the same) project member replies to that comment with `/ok-to-test`.
• Then the PipelineRun associated with the MR must be triggered successfully.

  ---

• Given a Merge Request with multiple comments from various users.
• When Pipelines-as-Code processes the comments to check for permissions.
• Then the GitLab API to get project membership for a specific user ID should only be called once for that user.
• Subsequent permission checks for the same user must be served from the in-memory cache without making a new API call.

  ---

• A `/ok-to-test` command from a non-member in any comment or reply does not trigger a PipelineRun.

INVEST Checklist

✅ Dependencies identified

✅ Blockers noted and expected delivery timelines set

✅ Design is implementable

✅ Acceptance criteria agreed upon

✅ Story estimated

Legend

⚫ Unknown

✅ Verified

❌ Unsatisfied

Done Checklist

✅ * Code is completed, reviewed, documented and checked in
✅ * Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
✅ * Continuous Delivery pipeline(s) is able to proceed with new code included
✅ * Customer facing documentation, API docs etc. are produced/updated, reviewed and published
✅ * Acceptance criteria are met