policycoreutils: pp: mimic require block support in CIL

CIL does not have any concept of require blocks. Instead, CIL relies on
whether or not all statements inside an optional block resolve to
determine if an optional block should be enabled/disabled. However, a
small number of optional statements require a type that is not actually
used in the optional block. In old style policy, this would cause the
optional block to be disabled. However, in CIL, because the type is never
used, the optional block will remain enabled.

To maintain compatibility, we modify pp2cil to create a new attribute,
cil_gen_require, and all types/roles/attributes that are required in a
pp module/optional block are associated with this attribute. Thus, if a
type is required but not used, it will still fail to resolve in the
typeattributeset statement, causing the optional to correctly be
disabled.

Note that when compiling the CIL this generated from compiling refpolicy
pp modules with pp2cil, the extra CIL statements cause ~12.6MB increase
in maximum memory usage (129.7 MB to 142.3 MB). Though, compilation time
decreases by ~35% (26 seconds to 17 seconds).

Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Reviewed-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Reported-by: Sven Vermeulen <sven.vermeulen@siphos.be>
policycoreutils: pp: define type aliases in the correct scope

Previously, type aliases were converted to CIL in the global namespace,
regardless of which scope they were actually defined in. So essentially
type aliases could never be in optionals. For the most part this worked,
however, in some small number of cases, a type alias could reference a
type defined inside an optional. If that optional was disabled, the type
would be disabled and so the type alias would fail to resolve, causing
policy to fail to build.

Unfortunately, type alises are stored in pp modules different than other
symbols (e.g. types/roles/etc) so they must be added to scopes
differently. So this patch gathers up all type aliases in a list and
keeps track of which scope each type alias is defined in. When we enter
a new scope, use that list to determine which type alias are defined
there and print the appropriate CIL statements.

Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Reviewed-by: Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com>
Bump to release candidate 6