[feature] restore optimization

[gsmolk]

Currently, every backup in incremental chain restored in an extremely inefficient way:

PAGE (fileA is known to be deleted)
FULL (contain fileA)

fileA is still getting copied and then deleted.
So when restoring incremental chain, every backup should have destination backup filelist.

[za-arthur]

Pushed into issue_63 branch. I introduced pgFile->rel_path to easily store relative paths instead of using GetRelativePath(). GetRelativePath() is still is used in the code though.

[gsmolk]

Are we going to get rid of GetRelativePath() completely?

[za-arthur]

Yes, but only in the following patches. New patches shouldn't use GetRelativePath() and maybe someday we'll remove it completely.

[gsmolk]

Am I correct that GetRelativePath() is still needed when dealing with backups, produced by previous pg_probackup versions?

[za-arthur]

No, GetRelativePath() isn't need for backward compatibility, since path in backup_content.control is relative path.

[gsmolk]

Oh, right, forgot about it.

[gsmolk]

Added new test in master 87f28e7, additional tests for external dirs and merge will be added shortly

[gsmolk]

So this code should not be needed now, right?
https://github.com/postgrespro/pg_probackup/blob/master/src/restore.c#L453

[gsmolk]

I`m sorry, wrong branch.

[gsmolk]

Well, looks like everything is ok.
I think it can be merged to master.