Make read callbacks graceful for gitlab_project_share_group, gitlab_branch_protection and gitlab_label resources

[ymatsiuk]

Every time resource got changed manually, provider fails and the only fix is to remove failing resource from the state. If resource doesn't exist in gitlab, terraform should be informed and state cleaned, instead of failing with error.
Inspired by #209

[roidelapluie]

This is the expected behaviour.

The provider uses gitlab ID's to identify resources. That ID can not change.

If a resource has a different id in gitlab, then it is not the resource that was created by terraform.

Note: in addition to that, if you do not have the rights to read resources, we also get a 404 from the API. It means that the state could be destroyed if someone launches the plug-in with bad credentials.

[ymatsiuk]

@roidelapluie So in other words if I created protected branch with terraform and someone removed protection using gitlab admin interface it's expected for terraform to fail next plan by design?

I'm very curious, because here it says:

If the ID is updated to blank, this tells Terraform the resource no longer exists (maybe it was destroyed out of band). Just like the destroy callback, the Read function should gracefully handle this case.

[roidelapluie]

For the protected branch we could adopt this.

However for git repos etc I would not do it because of the mentionned issue: if you do not have the rights to read resources, we also get a 404 from the API. It means that the state could be destroyed if someone launches the plug-in with bad credentials.

[roidelapluie]

I would be happy if gitlab would return 403 but they return 404.

[ymatsiuk]

gitlab_project_share_group causes the same amount of manual actions as gitlab_branch_protection. Shall I rebase for both resources and revert the rest?

[roidelapluie]

Also gitlab_labels

[ymatsiuk]

could you please re-open this PR?