Remove per-participant permission checks from participants

What does this MR do and why?

Following the removal of per-source permission checks from participants (!213623 (merged)), this MR removes per-participant permission checks to further improve performance.

Key changes:

• Eliminate the filtered_participants_hash, filter_by_ability and can_read_participable? methods from the Participable concern.
• Remove permission-based filtering from participants and participant? methods.
• Ensure all participants are shown regardless of their current access level to the issuable parent like project or group.

This change aligns with the goal of showing all participants who have ever interacted with an issuable like an issue or MR, even if their permissions have changed since their participation.

Notes

• The AppSec team has been involved (ref 1 and ref 2) in the decision-making process regarding the removal of participant-related permission checks.
• Even if a user remains listed as a participant, they won't receive notifications without project/group access because a separate permission check is performed when sending emails.
• We've decided to keep the current mention-related behaviour unchanged for now. Any adjustments to how participants are computed, with a focus on explicit user actions rather than mentions, will be discussed and handled separately via https://gitlab.com/gitlab-org/gitlab/-/issues/582362.
• The documentation was updated in a previous MR to ensure that participant list visibility is clearly described and not considered a security vulnerability.

References

• #582001 (closed)
• https://gitlab.com/gitlab-org/gitlab/-/issues/577825
• https://gitlab.com/gitlab-org/gitlab/-/issues/574228
• !213623 (merged)

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Create a private project.
2. As User 1, create a new issue and assign User 2 (who is also a member of the project).
   • Expected result: Both User 1 and User 2 appear in the participants list.
3. Unassign User 2 and assign User 3 (another project member).
   • Expected result: User 1, User 2, and User 3 all appear in the participants list.
4. Remove User 2 from the project.
5. Verify that the number of participants has not changed.
   • Expected result: All three users (User 1, User 2, and User 3) remain visible in the participants list.
   • Before this change, User 2 would no longer appear because they no longer had access to the project or its issue.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.