avocado.core.output: Make OutputManager to handle pagination

One less than ideal aspect of our output module is that
plugins have to use a bunch of primitives of that module
out of necessity (such as get_paginator()).

Avocado needs a single entity that controls output for
the application. Let's start by covering the needs of
plugins, by introducing the list_mode argument to the
constructor of that class. When list_mode is set to
True, instead of the regular logging system we'll use
the output paginator class (that will use less if
available to display large amounts of output line with
pagination. Also, turn a useful method that was private
to public, ._log() -> .log().

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.core.output: Remove unused 'avocado.utils' logger from OutputManager

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.core.output: Rename OutputManager() to View()

As this class is evolving to become the one stop shop
for avocado output needs. Also, move some methods around
to help organize better the class layout.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.plugins.runner: Port to View() class

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.core.output: View() API overhaul

Organize the log APIs into:

* APIs that log operation statuses (.log_ui_status)
* More generic ones (.log_ui)

The distinction helps and gives more insight on what is
actually accomplished by each method. This is a fairly
intrusive change, although it received a fair bit of
testing before submission.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
Avocado: Add 2 new loggers 'avocado.test.stdout' and 'avocado.test.stderr'

Both will be important to store stdout and stderr streams
of tests for our future output check mode feature.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.core.output: Add LogFile object

Add a new object that can properly stub the stdout
and stderr streams for test subprocess executions,
delivering the messages to our stdout and stderr
loggers instead of directly to sys.stdout and/or
sys.stderr.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.job: stub stdout and stderr of test subprocesses to loggers

So whatever goes to the stdout/stderr of those subprocesses
gets properly logged in the stdout.actual/stderr.actual files
that the test execution will record.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.test: Create the 'stdout.actual' and 'stderr.actual' files for tests

Create the file handler for both streams and connect them to
the loggers, so whatever goes on the stdout of those tests
will be logged to those files.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.utils.process: Add record_stream_files param to APIs

Add the new record_stream_files to the process APIs, which
basically means, 'log stdout and stderr of that subprocess
to the test stdout.actual and stderr.actual files'. We
thought about making that transparent, but frequently people
will want to execute programs inside tests that are part
of the setup of those tests, for example, make commands and
the such.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
examples/tests/synctest.py: Add record_stream_files arg to synctest call

Add the record_stream_files argument to the synctest
command execution, to showcase how to use it. The idea
is that the full output of the synctest command goes to
the 'stdout.actual' and 'stderr.actual' files, excluding
all previous 'make' commands used to build the test suite.

With this, we pave the way for a feature that people can
use to record the outputs of commands, and later compare
with the reference output automatically.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado.test: Make dropin tests to log their stdout/stderr streams

Add the record_stream_file param to the execution of the
dropin tests. This ensures their outputs are properly logged.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
avocado: Introduce --output-check-record option to test runner

It is a common use case in test automation that we want
to check the output of the test or applications started
by it and compare it with a reference output.

Introduce the option --output-check-record, that will
run the test you specify and generate the files
'stdout.expected' and 'stderr.expected' in the test
data dir (same directory as the source file, with the
name 'filename.data').

In case that option is not provided, if there is an
expected stdout or stderr file, those files will be
checked against the output the test just produced. If
no files are found, the check will be skipped. If
--output-check-record, no check will be made on that
particular execution, since we are recording what
is going to be expected in future test runs.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
examples/tests/synctests: Add stdout and stderr reference files

These files were captured using our new runner option

$ avocado run --output-check-record all examples/tests/synctest.py

And should now be checked every time that particular test
will run.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
docs: Add Output Check Mode documentation

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
examples/tests: Add env_variables.sh

Add an example of how avocado exposes information to
shell scripts through environment variables.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
examples/tests: Add output_check.sh

Add an example of script that will have its output
checked if executed through avocado.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
man page: fix the proper author of the project

And not the (original) author of the man page.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
avocado/utils/crypto.py: remove get_random_string function

The exactly same function body is present under avocado/data_factory.py,
under the name generate_random_string.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
avocado/utils/crypto.py: remove compatibility code for older Python versions

Avocado needs Python 2.7.0 and later, so there's no point in maintaining
compatibility code with older Python versions.

Signed-off-by: Cleber Rosa <crosa@redhat.com>