sstatesig/sstate: Add support for locked down sstate cache usage

I've been giving things some thought, specifically why sstate doesn't
get used more and why we have people requesting external toolchains. I'm
guessing the issue is that people don't like how often sstate can change
and the lack of an easy way to lock it down.

Locking it down is actually quite easy so patch implements some basics
of how you can do this (for example to a specific toolchain). With an
addition like this to local.conf (or wherever):

SIGGEN_LOCKEDSIGS = "\
gcc-cross:do_populate_sysroot:a8d91b35b98e1494957a2ddaf4598956 \
eglibc:do_populate_sysroot:13e8c68553dc61f9d67564f13b9b2d67 \
eglibc:do_packagedata:bfca0db1782c719d373f8636282596ee \
gcc-cross:do_packagedata:4b601ff4f67601395ee49c46701122f6 \
"

the code at the end of the email will force the hashes to those values
for the recipes mentioned. The system would then find and use those
specific objects from the sstate cache instead of trying to build
anything.

Obviously this is a little simplistic, you might need to put an override
against this to only apply those revisions for a specific architecture
for example. You'd also probably want to put code in the sstate hash
validation code to ensure it really did install these from sstate since
if it didn't you'd want to abort the build.

This patch also implements support to add to bitbake -S which dumps the
locked sstate checksums for each task into a ready prepared include file
locked-sigs.inc (currently placed into cwd). There is a function,
bb.parse.siggen.dump_lockedsigs() which can be called to trigger the
same functionality from task space.

A warning is added to sstate.bbclass through a call back into the siggen
class to warn if objects are not used from the locked cache. The
SIGGEN_ENFORCE_LOCKEDSIGS variable controls whether this is just a warning
or a fatal error.

A script is provided to generate sstate directory from a locked-sigs file.

(From OE-Core rev: 7e14784f2493a19c6bfe3ec3f05a5cf9797a2f22)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstatesig: Improve to handle locking of multiple machines

Instead of a single monolithic SIGGEN_LOCKEDSIGS, split this into
separate variables, one per sstate package architecture. Add in
a new SIGGEN_LOCKEDSIGS_TYPES variable which lists the package
architectures to load in.

SIGGEN_LOCKEDSIGS_TYPES is made machine specific using overrides.

Also sort the hashes in the lists by PN to make diffing them easier.

(From OE-Core rev: d8b0ce35981931a39e7db9d8e78de6e009b34688)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstatesig: Improve the support for locked down sstate cache usage

Add code in the sstate hash validation code to ensure it really did
install these from sstate since if it didn't should to warn/abort
the build. The judgment condition is:
1) If a build is replaced by locked sstate-cache, it will triger a
   warn/error;
2) If objects are not used from the locked cache, it will triger a
   warn/error;
3) Use SIGGEN_LOCKEDSIGS_CHECK_LEVEL variable controls whether this
   is just a warning or a fatal error or nothing to report.

[YOCTO #6639]

(From OE-Core rev: 305912dce61c4fed0cbf631aa98a9e6f29db88e4)

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstatesig.py: Replace '_'s with '-'s in SSTATE_LOCKEDSIGS* names.

Using underscores in the "types" parts of the variable names can cause
unexpected issues with overrides. For example, if you have both
SSTATE_LOCKEDSIGS_x86_64 and SSTATE_LOCKEDSIGS_x86_64_i586, and i586
is in OVERRIDES, then you lose all of the contents in
SSTATE_LOCKEDSIGS_x86_64 and thus don't get some of the locked sstate.

Using '-'s in the variable names instead, eliminates these issues.

(From OE-Core rev: 6662c412a949a9f6b602c848e6303b19db7e5272)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstate: set SIGGEN_LOCKEDSIGS_CHECK_LEVEL default to error

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
sstatesig: fix overrides behaviour to remove SIGGEN_LOCKEDSIGS_i586

Require a sig file which SIGGEN_LOCKEDSIGS_i586 is not null, but
the actual SIGGEN_LOCKEDSIGS_i586 is null.
Invoking 'bitbake -e' and we got:
...
 3935 # $SIGGEN_LOCKEDSIGS_i586 [2 operations]
 3936 #   set /path/to/locked-sigs.inc:8576
 3938 #   del data_smart.py:406 [finalize]
 3939 #     ""
...

It was caused by the following commit:
...
(Bitbake rev: 899d45b90061eb3cf3e71029072eee42cd80930c)
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Tue May 31 23:52:50 2011 +0100

    bitbake/data_smart: Change overrides behaviour to remove expanded
      variables from the datastore
...

We add prefix 't-' to type to workaround the overrides behaviour.

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
sstatesig: Only dump incremental locked signatures

The idea of incremental sig is:

New sig file = Old sig file (if available) + New sig items in current build.

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>