'Remove blobs' feature fails on previously forked projects
<!--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=537390)
</details>
<!--IssueSummary end-->
<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "type::bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
[Remove blobs](https://docs.gitlab.com/user/project/repository/repository_size/#remove-blobs) feature might not work if the following conditions are met:
* A fork was created for the project
* The fork was later removed
* Offending blobs are part of the old pool
### Steps to reproduce
* Create a project as interrnal or public
* Add some blobs
* Fork the project
* Remove the fork
* Try deleting the blobs using [Remove blobs](https://docs.gitlab.com/user/project/repository/repository_size/#remove-blobs) feature.
### Example Project
<!--If possible, please create an example project here on GitLab.com that exhibits the problematic
behavior, and link to it here in the bug report. If you are using an older version of GitLab, this
will also determine whether the bug is fixed in a more recent version.-->
### What is the current *bug* behavior?
Blobs will not be removed.
### What is the expected *correct* behavior?
Blobs should be removed if the project is no more in a fork relationship.
### Relevant logs and/or screenshots
<!--Paste any relevant logs - please use code blocks (```) to format console output, logs, and code
as it's tough to read otherwise.-->
### Output of checks
<!--If you are reporting a bug on GitLab.com, uncomment below-->
<!--This bug happens on GitLab.com-->
<!--and uncomment below if you have /label privileges-->
<!--/label ~"reproduced on GitLab.com"-->
<!--or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not-->
#### Results of GitLab environment info
<!--Input any relevant GitLab environment information if needed.-->
<details>
<summary>Expand for output related to GitLab environment info</summary>
<pre>
(For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:env:info\\\`) (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\`)
</pre>
</details>
#### Results of GitLab application Check
<!--Input any relevant GitLab application check information if needed.-->
<details>
<summary>Expand for output related to the GitLab application check</summary>
<pre>
(For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:check SANITIZE=true\`) (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\`) (we will only investigate if the tests are passing)
</pre>
</details>
### Workaround
To check if the files are still part of the repository, even after running remove blobs and prune objects tasks (30 minutes later) from the UI, run the following commands from within the hashed path of the repository in the server:
```bash
sudo -u git /opt/gitlab/embedded/bin/git cat-file -e <blob_id>
echo $?
```
If the above output returns `0`, then the file exists. To get the pool repo path, run:
```bash
cat objects/info/alternates
```
Now, check if the project is part of the fork network:
```ruby
project = Project.find_by_full_path('<namespace/project>')
project.fork_network
project.pool_repository.member_projects
```
If it is the only project that's part of its fork network, TAKE A BACKUP of the repository and then disconnect the pool:
```ruby
project = Project.find(<project_id>)
project.leave_pool_repository
```
This should delete the pool and the next gc/housekeeping should cleanup the dangling files. DO NOT run this step if the pool is being used by other projects.
issue