Merge the work on all.sh that was done on mbedtls-2.14.0 with the
changes from mbedtls-2.14.0 to mbedtls-2.16.0.
There is a merge conflict in test/scripts/all.sh, which is the only
file that was modified in the all.sh work branch. I resolved it by
taking the copy from the all.sh branch and applying the changes
between mbedtls-2.14.0 and mbedtls-2.16.0. These changes consisted of
two commits:
* "Add tests to all.sh for CHECK_PARAMS edge cases": adds two
test components which are reproduced here as
test_check_params_without_platform and component_test_check_params_silent.
* "tests: Backup config.h before modifying it": moot because the
component framework introduced in the all.sh branch backs up config.h
systematically.
In all.sh, always save config.h before running a component, instead of
doing it manually in each component that requires it (except when we
forget, which has happened). This would break a script that requires
config.h.bak not to exist, but we don't have any of those.
Call cleanup from run_component instead of calling it from each
individual component function.
Clean up after each component rather than before. With the new
structure it makes more sense for each component to leave the place
clean. Run cleanup once at the beginning to start from a clean slate.
Move almost all the code of this script into functions. There is no
intended behavior change. The goal of this commit is to make
subsequent improvements easier to follow.
A very large number of lines have been reintended. To see what's going
on, ignore whitespace differences (e.g. diff -w).
I followed the following rules:
* Minimize the amount of code that gets moved.
* Don't change anything to what gets executed or displayed.
* Almost all the code must end up in a function.
* One function does one thing. For most of the code, that's from one
"cleanup" to the next.
* The test sequence functions (run_XXX) are independent.
The change mostly amounts to putting chunks of code into a function
and calling the functions in order. A few test runs are conditional;
in those cases the conditional is around the function call.
Document when a context must be initialized or not, when it must be
set up or not, and whether it needs a private key or a public key will
do.
The implementation is sometimes more liberal than the documentation,
accepting a non-set-up context as a context that can't perform the
requested information. This preserves backward compatibility.
