OTP kernel application use "logger_level" configuration for configuring
level in primary configuration.
rebar3 uses "logger_info" for this purpose - ths is little bit confusing
and probably mistake.
This commit will unify behavior between kernel and rebar3o

Fixes: 0303567d95 ("Reload logger config in shell")

Patch up and add tests on #2112

This adds an additional loading and merging of options for EDoc using
the values from the top-level along with those specified in the
rebar.config of an umbrella application.

The app-specific config values are prepended to the global ones; this
can likely cause some problems with manual path handling, but is
unlikely to happen in practice and the rest seems to work fine based on
order

Fixes the issue in #2114

This allows to reduce the number of noise to only checking deps' app
files when they're built, rather than on every run.

Since main apps and checkouts are still compiled every time, the linting
takes place there and then with a higher frequency.

rebar3's shell allows people to set applications as blacklisted to
prevent them from being reloaded because that can cause crashes.
However, as part of its normal operations, rebar_paths unloads all
modules that are currently not "owned" by at least one process,
considering them safe to do so.

These two behaviours, put together, lead to an odd thing where some
modules are suddenly unloaded and not in path, and that can be
confusing.

This calls for a unification of both features. We could decide to be
pushing the complexity of rebar3's shell into rebar_path so it knows of
blacklists, but this would be a bad idea because rebar_agent already
owns all the damn hack.

So instead this fix adds an optional call within rebar_agent's
blacklisted applications handling that calls `code:ensure_loaded/1` on
their modules. This avoids forcing any code change that would cause a
crash, but reinstates unloaded paths that could be confusing.

Addresses some comments in #2013

Co-Authored-By: Fred Hebert <mononcqc@ferd.ca>

Overrides should apply to a layer below where they are declared. This
patch makes it so if the project root is an application (i.e. it isn't
'root' and therefore not an umbrella project), we omit applying
overrides in rebar_app_discover.

This in turn required changing a bunch of tests, because all the tests
worked with the idea that all overrides applied to all apps to validate
that they get inherited properly. The changes re-structure the cases so
they are written with an umbrella app, demonstrating that the changes
stick.

- fix some bad typespec
- bump the meck version for good fortune

Signed-off-by: Pierre Fenoll <pierrefenoll@gmail.com>

Deps command shows an * if the local state of the dependencies do not
match the config file, highlighting the differences between the lock
file and the config file if there are any.

This patch does two things:

1. it broadens the interface for the compiler module so that
   non-first-file modules can possibly be parallelized. This is done by
   dynamically switching on `[ListOfFiles]`, which remains sequential as
   before, or `{[SeqPriority], [Parallel]}`, which divides regular files
   between higher priority ones and those that can be in parallel
2. implements this mechanism in the rebar compiler, based on the erl
   file digraph. If a file has an in-neighbour, it is depended on by
   another file. The mechanism therefore makes it so all files that have
   dependants get compiled in their strict relative sequential order
   first, and then the undepended-on files get compiled together in
   parallel.

By running:

  ./rebar3 ct --suite test/rebar_compile_SUITE.erl --case \
  recompile_when_parse_transform_inline_changes --repeat 50

the previous iteration of this would rapidly fail, and this one succeeds
every time.

Support for parallel compilation of *.erl file was dropped before 3.0 release.
However, our tests for a project containing ~500 source files show substantial gain, lowering compilation time from 58 seconds to 18 on a MacBook Pro 15" (4 cores, 8 threads), and to just 10 seconds on Xeon-D machine.

deps command was printing an * even when deps were updated, this commit
makes it call rebar_fetch:needs_update/2 for each of them

Previously all escriptize hooks from all apps in the project were
executed, which could lead to issue in case of dependencies on artifacts
which are created by these hooks.

Now the behaviour is similar to the handling of other non-global hooks.

This currently just checks for the existence of the description and applications
keys and that the applications list has kernel and stdlib in it.