bad logging around broken restore_command

If the restore command claims to have succeeded, but fails to have created a file with the right name (due to typos or escaping or quoting issues, for example), no complaint is issued at the time, and it then fails later with a relatively uninformative error message like "could not locate required checkpoint record".

        }
        else
        {
            /* stat failed */
            if (errno != ENOENT)
                ereport(FATAL,
                        (errcode_for_file_access(),
                         errmsg("could not stat file \"%s\": %m",
                                xlogpath)));
        }

I don't see why ENOENT is thought to deserve the silent treatment.  It seems weird that success gets logged ("restored log file \"%s\" from archive"), but one particular type of unexpected failure does not.

I've attached a patch which emits a LOG message for ENOENT.  The exact wording doesn't matter to me, I'm sure someone can improve it.  Alternatively, perhaps the message a few lines down, "could not restore file", could get promoted from DEBUG2 to LOG when rc indicates success.  But I don't think we need any more messages which say "Something went wrong: success".

This is based on the question at https://stackoverflow.com/questions/60056597/couldnt-restore-postgres-v11-from-pg-basebackup.  But this isn' the first time I've seen similar confusion.

Cheers,

Jeff