Errcheck phase 1 (#1715)

* Avoid redundant logging in migrations

Return the error and let the caller handle the logging of the error if
needed.

While here, defer m.Close() to the function boundary.

* Treat errors as values

Use %v rather than %s and pass the errors directly.

* Generate a wrapped error on stat-failure

* Log 3 unchecked errors

Rather than ignore errors, log them at
the WARNING log level.

The server has been functioning without these, so assume they are not at
the ERROR level.

* Propagate errors upward

Failure in path generation was ignored. Propagate the errors upward the
call stack, so it can be handled at the level of orchestration.

* Warn on errors

Log errors rather than quenching them.

Errors are logged at the Warn-level for now.

* Check error when creating test databases

Use the builtin log package and stop the program fatally on error.

* Add warnings to uncheck task errors

Focus on the task system in a single commit, logging unchecked
errors as warnings.

* Warn-on-error in API routes

Look through the API routes, and make sure errors are being logged if
they occur. Prefer the Warn-log-level because none of these has proven
to be fatal in the system up until now.

* Propagate error when adding Util API

* Propagate error on adding util API

* Return unhandled error

* JS log API: propagate and log errors

* JS Plugins: log GQL addition failures.

* Warn on failure to write to stdin

* Warn on failure to stop task

* Wrap viper.BindEnv

The current viper code only errors if no name is provided, so it should
never fail. Rewrite the code flow to factor through a panic-function.

This removes error warnings from this part of the code.

* Log errors in concurrency test

If we can't initialize the configuration, treat the test as a failure.

* Warn on errors in configuration code

* Plug an unchecked error in gallery zip walking

* Warn on screenshot serving failure

* Warn on encoder screenshot failure

* Warn on errors in path-handling code

* Undo the errcheck on configurations for now.

* Use one-line initializers where applicable

rather than using

  err := f()
  if err!= nil { ..

prefer the shorter

  if err := f(); err != nil { ..

If f() isn't too long of a name, or wraps a function with a body.

pkg/database/database.go

@@ -232,6 +232,7 @@ func RunMigrations() error {
 	if err != nil {
 		panic(err.Error())
 	}
+	defer m.Close()
 
 	databaseSchemaVersion, _, _ = m.Version()
 	stepNumber := appSchemaVersion - databaseSchemaVersion
@@ -240,14 +241,10 @@ func RunMigrations() error {
 		err = m.Steps(int(stepNumber))
 		if err != nil {
 			// migration failed
-			logger.Errorf("Error migrating database: %s", err.Error())
-			m.Close()
 			return err
 		}
 	}
 
-	m.Close()
-
 	// re-initialise the database
 	Initialize(dbPath)
 
@@ -255,7 +252,7 @@ func RunMigrations() error {
 	logger.Info("Performing vacuum on database")
 	_, err = DB.Exec("VACUUM")
 	if err != nil {
-		logger.Warnf("error while performing post-migration vacuum: %s", err.Error())
+		logger.Warnf("error while performing post-migration vacuum: %v", err)
 	}
 
 	return nil