Prevent channel buffer allocation larger than memory

Prevent channel buffer allocation larger than memory

Background
==========
Until recently (before lttng-modules commit 1f0ab1e) it was possible to
trigger an Out-Of-Memory crash by creating a kernel channel buffer
larger than the currently usable memory on the system. The following
commands was triggering the issue on my laptop:
  lttng create
  lttng enable-channel -k --subbuf-size=100G --num-subbuf=1 chan0

The lttng-modules commit 1f0ab1e adds a verification based on an
estimate to prevent this from happening. Since this kernel tracer sanity
check is based on an estimate, it would safer to do a similar check on
the session daemon side.

Approach
========
Verify that there is enough memory available on the system to do all the
allocations needed to enable the channel. If the available memory is
insufficient for the buffer allocation, return an error to the user
without trying to allocate the buffers.

Use the `/proc/meminfo` procfile to get an estimate of the current size
of available memory (using `MemAvailable`). The `MemAvailable` field was
added in the Linux kernel 3.14, so if it's absent, fallback to verifying
that the requested buffer is smaller than the physical memory on the
system.

Compute the size of the requested buffers using the following equation:
  requested_memory = number_subbuffer * size_subbuffer * number_cpu

The following error is returned to the command line user:
  lttng enable-channel -k --subbuf-size=100G --num-subbuf=1 chan0
  Error: Channel chan0: Not enough memory (session auto-20181121-161146)

Side effect
===========
This patch has the interesting side effect to alerting the user with an
error that buffer allocation has failed because of memory availability
in both --kernel and --userspace channel creation.

Drawback
========
The fallback check on older kernels is imperfect and is only to prevent
obvious user errors.

Note
====
In the future, there might be a need for a way to deactivate this check
(by using an environment variable) if a case arises where
`/proc/meminfo` doesn't accurately reflect the state of memory for a
particular use case.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>