sf: vds: Selectively compose displays via HWC

1. Replace static force copy flag with member variable

The decision to copy a virtual display using the WriteBack path will be
done when the display is created. We initialize the member variable to
false meaning all virtual display devices are composed via GLES.

2. Select which displays to compose based on sink usage flags

We should compose a display using HWC only if the sink usage contains
GRALLOC_USAGE_PRIVATE_WFD and GRALLOC_USAGE_HW_VIDEO_ENCODER flags.

If this condition is not met then the display is composed using GLES.
This means that GLES composes directly into the sink buffer and signals
the consumer. Furthermore, it is expected that any color conversion will
be handled on the consumer side.

3. Add debug hook for ScreenRecord use case

We add a debug hook which serves to by-pass the checks imposed by (2).
This is useful for debugging purposes and allows us to test VDS
end-to-end when WFD is not working on a particular build.

The debug hook is through the system property: debug.hwc.screenrecord

4. Update composition checks

-mFbProducerSlot is always at least 0 so there is no point in validating
 it when in advanceFrame().
-Release scratch buffers in onFrameCommitted as long as mFbProducerSlot
 is valid.

Change-Id: I2964e2f8d0b3e848895cdf4f41df8a5d2739ddad

sf: vds: Allocate display ID for displays composed/copied by HWC

We make VDS responsible for deciding if a display will be composed
by HWC. This is primarily based on the usage flags on the sink
buffer, as well as on the requested display resolution.

With this approach, there are two possible scenarios in which we
make a decision that applies while the display is connected:

1. The display will be composed by HWC, and we use WB to produce
   the final output.
2. The display will be composed by GLES/GPU and HWC has no knowledge
   of this display.

For case 1) we will have a valid display ID and for case 2) we will
have NO_MEMORY as the display ID.

Change-Id: I92b1e8b5973fea1a894caa7588dd95a1e551dd8e

sf: vds: Add support for secure virtual displays

1. Propagate secure flag on display creation

In SurfaceFlinger we have information that tells us whether a
display is secure or not. We need to propagate this information
when creating the corresponding virtual display, allowing us to
configure output buffers with the correct (secure) usage flags.

2. Use secure heap only for sessions that need HW level protection

Use MM heap only if the secure session needs hardware level
protection. At the present moment we are assuming that only displays
with the GRALLOC_USAGE_HW_ENCODER need hardware level protection.

Change-Id: I7e0d42ba3a81d1f5c42b1074e3018826b38b7a8d
Fix compile for non-caf display variant with BSP enabled

Change-Id: I235ecb331a7e35a2456740c465b9a4a618af5403
Ensure that app lib symlinks are correctly labeled when created.

At present, the app lib symlinks are created before setting
the package directory security context, and therefore default
to system_data_file.  Upon a later restorecon_recursive,
they are relabeled to the same type as the package directory,
e.g. app_data_file.  Avoid this inconsistency by setting the
package directory security context before creating the symlink
so that it inherits the same security context.

Change-Id: I1ee6ccd8a2aa63a4d2efda67f313c97932235911
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>