Handle DeleteObjectPool calls in Praefect

Praefect currently proxies DeleteObjectPool calls to Gitalys like any other mutating RPC. This has the same problem as RemoveRepository previously had; a pool can be deleted from the disk and it's metadata record still left in the database. This can then cause problems as Praefect believes a pool replica still exists where one doesn't exist.

Praefect doesn't even treat DeleteObjectPool as a repository removing RPC. This means the deletions have never been replicated to the secondaries and the pool metadata records have been left in place. This then causes the reconciler to repeatedly attempt to reconcile from a non-existing primary pool replica to the secondaries.

This commit fixes both issues by handling pool deletions in Praefect. Similarly to RemoveRepository, the metadata record of the pool is first deleted and only then the pool is attempted to remove from the Gitalys that have it. This ensures atomicity of the removals when Praefect is rewriting the replica paths.

With the behavior fixed, the Praefect specific test asserations can be removed as the behavior now matches what how a plain Gitaly would behave.

The handler in Praefect is tested via the same tests that test the handler in Gitaly. Adding separate tests doesn't make sense as external behavior of the the handlers should match and the handler shouldn't exists in Praefect if it is removed from Gitaly.

Related to: #3485 (closed)
Closes: #4078 (closed)
Closes: #3742 (closed)