Ignore 404 errors in GitLab group iteration

[Meli1Git]

When making requests to the GitLab API, a 404 error can be returned in two scenarios: when attempting to access a resource for which the user lacks permissions, or when querying a resource that does not exist (or has just been deleted).

In the case of missing permissions, GitLab intentionally returns a 404 status code instead of the more conventional 403 to avoid revealing the existence of restricted resources.

To address this issue, this pull request proposes a solution to specifically handle 404 errors occurring on calls made to the /groups/xxx/projects endpoint. If a 404 error is encountered while attempting to list projects within a group, it suggests either a permissions issue or that the group does not contain any projects. In either scenario, it's optimal to manage this situation by proceeding with the iteration through other groups and providing the user with a consolidated list of projects that could be successfully retrieved. Rather than triggering a "404 Group Not Found" error :

The current approach, treating 404 errors as "true" errors and triggering retries via the error callback, leads to unnecessary retries and ultimately does not provide meaningful results.

By treating 404 errors on the /groups/xxx/projects endpoint as expected behavior and handling them accordingly, we can improve the robustness and efficiency of our API requests.

[Meli1Git]

Hi @davidjgraph , could you please take a look at this pull request? Thank you.

[davidjgraph]

Please read the project README.

[Meli1Git]

@davidjgraph thank you for your response. Since your development process does not allow for external contributions, I have created an issue to explain the bug: #4528. I kindly request that you review it and consider its inclusion in future releases.