When running the dump command, include the specific configuration file
provided as part of the backup. Currently we only zip up custom/ and this
misses the config file if it is somewhere else, like /etc/gitea/app.ini
Fixes#6034
* Set session and indexers' data files rel to AppDataPath
The setting AppDataPath is now relative to the working directory.
The session svc's PROVIDER_CONFIG now defaults to AppDataPath/data/sessions.
The issue indexer's IssuePath now defaults to AppDataPath/indexers/issues.bleves.
* fix bug
This change corrects a few logging issues:
* Standardized formatting errors with '%v'.
* Standardized failure warning word usage.
* Corrected an instance of using the standard log library when
the gitea log library should be used instead.
Now, the dump cmd uses setting.CustomPath and setting.LogRootPath
instead of setting.WorkDir which was kind of broken if the gogs
binary was in a different directory than gogs data.
Additionally, the backup of setting.CustomPath directory is only done
if it exists.
Using a tmp dir makes gogs dump more robust to concurrent runs.
It also permits an easier cleaning of the tmp files (gogs-db.sql and
gog-repo.zip) by just removing the tmp dir.
As a side effect, it partially fix bugs on workdir.
Previously, 'gogs dump' created the archives in the current directory,
and tried to include these archives from the directory where the
gogs binary lies.
ex: if gogs binary is in /usr/bin/gogs, and gogs dump is run from /tmp/,
/tmp/gog-repo.zip is created, but gogs dump tried to include
/usr/bin/gogs-repo.zip.
The dump cmd did not check the return value of the z.AddFile or
z.AddDir when building the final archive.
It caused the dump command to succeed even if an error occurred.
The resulted dump archive could be corrupted/empty.
(errors could be various: removal by a concurrent process, disk full,
bugs in the dump cmd itself)
