Project initialisation fails if any member account is blocked/banned/ldap_blocked

A recent update to Gitlab 14.10 at CERN started to cause problems for our Ghostflow instance at the project initialization/refresh stage when getting members. The GetProjectMembers error would be triggered, with the ultimate cause a NoSuchUser error from rust-ghostflow. The user that triggered the error is marked as "Blocked" in the member list of the Gitlab project (whose membership is created through LDAP synchronisation).

Using curl to query the API on the instance, it's clear that blocked user info is not accessible through the users?username=<handle> endpoint, though the account is still present and queryable via the users/:ID one. CERN IT pointed us to this MR in Gitlab which looks to have introduced the change and raised the issue for us as our service account for ghostflow doesn't have admin rights. This might be an oddity of using LDAP to add members to the project, and they therefore still appear in the list of members, even if their account is in the blocked/banned/ldap_blocked state (I can't test this as I can't now search/add a blocked Gitlab account directly 😆).

A possible fix would be to filter the list of members returned in GitlabService::members though this might need the state adding to the types::Member struct? I can propose a Merge Request, but wanted to report and check on this route for a fix first! We can of course test/confirm at CERN, but if there's a way to do this through the unit tests as well, let me know.