Approval rules with users that have their access revoked could become impossible to satisfy
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=34548)
</details>
<!--IssueSummary end-->
### Summary
When creating an ApprovalRule (`ApprovalProjectRule` or `ApprovalMergeRequestRule`) and removing access from the users/groups who are supposed to approve for that rule, it becomes impossible to satisfy the rule.
### Steps to reproduce
1. Add a user as developer to a project
1. Create an approval rule with that requires 1 approval and link that developer to the rule
1. Remove the developer from the project
### Example Project
https://gitlab.com/reprazents-test-space-renamed/working/merge_requests/2
This merge request cannot be approved by `@toon`, so it can never be merged
### What is the expected *correct* behavior?
The rule does not display Toon as a developer, allowing the other users, if any to approve the merge request
### Possible fixes
It think we should filter out ineligible approvers from `ApprovalWrappedRule#approvers`, that would allow any other user linked to the rule to still approve.
If the rule becomes impossible to satisfy, we should display a warning asking to update the rule.
issue