Check GitLab directly for issue fork push access, instead of trying to keep track

Note that this MR only covers the "isMember" query. I wasn't sure if we'd want to fully remove "drupalorg_issue_fork_maintainers" table here or in a follow-up.

• MR: https://git.drupalcode.org/project/drupalorg/-/merge_requests/189
• Test URL: https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3...
• Members of the fork: https://gitlab1.code-dev.devdrupal.org/issue/config_notify-3316144/-/pro...

Needs review.

We do use this table to populate the crediting & committing table, so we’ll need to keep it. The number of patches includes the number of pushes to the issue fork.

We should move this to front-end JS to keep response times lower. Any delay in GitLab’s response wouldn’t hold up loading the base issue page.

The checking is now done totally via JavaScript.

I've added a parameter to the "forkInformation" method to allow skipping the check before rendering. If that's the case, we'll show a button to get access by default.

Then, via JS, if the user has access to the fork, the button disappears with a message informing about it.

Same testing information as in #4.

Ready for review again at https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3...
Feedback in the MR was addressed.

Deployed, and production does not have the same unexpected GraphQL behavior as dev. So deploy removing that parameter.

Automatically closed - issue fixed for 2 weeks with no activity.