libsmack: implement internal hash table of labels

Use hash table implemented internally for dictionary of labels.

Thanks to that some operations are more efficient:
-it is possible to use better hashing function than in hsearch:
 DJB2 algorithm is used, which is much better, than hashing function
 used in hsearch. Hashing function in hsearch causes, that on 32bit
 machines, all labels that have common first eight bytes,
 share same bucket and this cause many conflicts in combination of labels
 naming convention with domain-based prefixes. This leads to significant
 performance degradation in real system. This was not detected on tests
 so far, because labels for test policies were generated randomly.
-it is possible to calculate hash during label validation.
-it would not cause drastic complexity growth to have number of labels
 near to number of allocated buckets as it happens in hsearch.
-it would be possible to add number of labels exceeding number of
 allocated buckets.

Signed-off-by: Jan Cybulski <j.cybulski@samsung.com>
libsmack: add possibility of resizing table of labels

Signed-off-by: Jan Cybulski <j.cybulski@samsung.com>
libsmack: shrink few rule and label struct fields

Use smaller struct fields to optimize memory usage and speed.
On a 32-bit machine this saves 4 bytes per rule and 4 bytes per label.
Limit label length to 8 bits. It's max value is already limited to 255.
Limit label id to 16 bits. While policy with more than 2^16 labels is
theoretically possible, it would be handled very badly by kernel.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
libsmack: reorganize rule lists for struct smack_accesses

Until now rule list was implemented as single linked list of all rules
added into struct smack_accesses. This patch breaks this list into several
lists, with one list of rules per subject label.
Each element in array of labels describe single label and all rules when it's a
subject are added into this label's list.

This data structure is close to internal kernel data structures for Smack
rules. This allows for slightly better performance because rules are
grouped by subject.
More importantly though, this patch prepares ground for rule merging.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
libsmack: change semantics of rule allow_code and deny_code

Fields in struct smack_rule are used to store either set or modify rule.
Set rules used to be distinguished by having deny_code = -1.
It is more convenient to have it differently: allow_code describing bits
that are to be set, deny_code describing bits that are to be cleared.
With that semantics access_code = ~deny_code for set rules. This enables
easy replacement of change rules that can be simplified to a set rule.
Thanks José Bollo for original idea about simplifying modify rules.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
libsmack: merge rules with the same subject and object before applying them

All rules with the same subject and object will be merged into a single one
before applying rules to kernel or writing them to a file. The result will
consist of smaller number of rules, but they will have the same semantics.
This enhances performance greatly when there are a lot of rules to merge.
The merging code has negligible overhead when there are no merges to
perform.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>