Initial support for multiple restore archives (issue1069)

[jsmeix]

See #1069

I introduced the new RESTORE_ARCHIVES() array that
contains the restore input files for 400_restore_backup.sh

I did major changes in 400_restore_backup.sh
so that it now launches a separated restore subshell together
with the progress stuff for each element in RESTORE_ARCHIVES.

Together with changes in 070_set_backup_archive.sh
it does now already restore real incremental backups
(i.e. one full backup plus several incremental backups).

For example assume during several "rear mkbackup"
the backup directory contains:

2016-11-15-1502-F.tar.gz
2016-11-16-1057-I.tar.gz
2016-11-16-1100-I.tar.gz
2016-11-17-1324-F.tar.gz
2016-11-17-1348-I.tar.gz
2016-11-17-1354-I.tar.gz
2016-11-17-1451-I.tar.gz

then "rear recover" will restore those backups:

2016-11-17-1324-F.tar.gz
2016-11-17-1348-I.tar.gz
2016-11-17-1354-I.tar.gz
2016-11-17-1451-I.tar.gz

i.e. the latest full backup plus all incremental backups
afterwards.
The "rear recover" output looks then like (excerpt):

Restoring from '/tmp/rear.YKFtL4WiICTkRPF/outputfs/d108/2016-11-17-1324-F.tar.gz'...
Restored 2426 MiB [avg 70992 KiB/sec] OK
Restored 2426 MiB in 36 seconds [avg 69020 KiB/sec]
Restoring from '/tmp/rear.YKFtL4WiICTkRPF/outputfs/d108/2016-11-17-1348-I.tar.gz'...
Restored 11 MiB [avg 11288 KiB/sec] OK
Restored 11 MiB in 2 seconds [avg 5644 KiB/sec]
Restoring from '/tmp/rear.YKFtL4WiICTkRPF/outputfs/d108/2016-11-17-1354-I.tar.gz'...
Restoring... OK
Restoring from '/tmp/rear.YKFtL4WiICTkRPF/outputfs/d108/2016-11-17-1451-I.tar.gz'...
Restoring... OK
Restoring finished.

Note that when the backup archive is very small
the current progress stuff in 400_restore_backup.sh
(I did not change its behaviour) does not show
any "Restored ... MiB [avg ... KiB/sec]" message
because it waits initially one second and during that
one second the restore had already finished.

[jsmeix]

Now I re-implemented differential backup, cf.
#1069 (comment)

For my first tests now differential backup
and real incremental backup work well.

In particular I annihilated the RFC 1925 6a indirection
of using special timestamp.txt and basebackup.txt files
that caused more indirections (i.e. dirty hacks) as in
#1066 (comment)

Now incremental/differential backup works plain and simple
only on the file names of the backup archives.

This has the advantage that the admin can change
only the backup archives as he likes and
incremental/differential backup will "just work".
Of couse when the admin deletes required backup archives
(e.g. the full backup) then "rear recover" cannot restore
from what is not there.

Furthermore I made FULLBACKUPDAY an array so that
now on several weekdays a full backup can be triggered.

[jsmeix]

Regardless that for me it works well currently,
I will not merge it right now but wait over the weekend
so that others might be able to test it.

[jsmeix]

Furthermore I have to adapt the meanwhile outdated
other documentation that BACKUP_TYPE=incremental
is actually a differential backup.

The current behaviour is documented only in default.conf.

[jsmeix]

Finally I have to improve the messaging
because currently it shows same messages
for "rear mkbackup" and "rear recover"
but the messages about what backup will be created
are at least misleading in case of "rear recover" where
it should be shown what backups will be restored.

[jsmeix]

Tested again in several ways and usual backup
and incremantal and differential backup
all work for me.

I think the general approach with using
an RESTORE_ARCHIVES() array
to support multiple restore archives
is the right (and future-proof) way to go.

Therefore I will merge that major change now
so that all GitHub master code users will test it
so that in case of regressions I have sufficient time
to fix them properly until the next ReaR release.