Restore overlay for shutdown options

Change-Id: Ieeb4041429a484381dc8a10d08319b3c93ad4861
recovery: add a "rescue mode" (SD-boot recovery managing an eMMC install)

Recoveries which boot off SD card, but manage an eMMC install are
indispensable for recovering from certain catastrophes.  It's useful to
be able to create such a "rescue" recovery image without having to
modify the recovery initramfs; to facilitate this, check for a flag
under /boot on startup and operate on eMMC regardless of boot location
if it's present.

Change-Id: I95b5523a1371833b405c17dfbdc7b6475c82fad0
Move recovery_emmc_protect.sh script under recovery/

Change-Id: I47cdbb666c233693b326652f826b54fb510384ed
Support extending postrecoveryboot.sh via scripts on /boot

This allows special-purpose script-driven recovery images to perform
last-minute tasks, such as copying an OTA package that needs to be able
to unmount all filesystems to /tmp, before starting the recovery
operation.

Change-Id: I1b7f18c6fb039590cbda93a2dddb41a3d0b7173a
Handle the bootloader control block properly

The BCB is not just a flag -- it's a data structure laid out as follows
(bootable/recovery/bootloader.h):

struct bootloader_message {
    char command[32];
    char status[32];
    char recovery[1024];
};

Update the BCB as such instead of on an ad-hoc basis; once we do that,
we can allow the recovery to manipulate the BCB directly, which allows
automatic resumption of recovery tasks interrupted by a crash or power
failure.

Change-Id: Ib35cecad311faba889c5954288fd091efef73a7a
recovery: add support for command files in /boot

Android recoveries accept a list of commands to perform on startup in
/cache/recovery/command; while this is a good location for an installed
system to communicate with a recovery, it doesn't work for creating
special-purpose script-driven recovery images (for initial install or
repartitioning, for example).

As a solution, introduce a command file in /boot (we have to be able to
ship files in /boot to have a recovery image anyway, so this is a
natural place to put it), and copy the arguments from that file to the
bootloader control block on recovery startup so that they'll be picked
up.

Change-Id: Ic06850d02ef7d6f59f6ae99f3d0eef79b82e1857
recovery: move device init code into init.rc from postrecoveryboot.sh

The CM recovery doesn't invoke postrecoveryboot.sh, so if we ever want
to use that recovery, we need to get the basic device init code out of
postrecoveryboot.sh.  init.recovery.${ro.hardware}.rc is used by all
known recoveries (it's part of AOSP), so let's put the device init stuff
there instead.

Change-Id: Ib6cd279c6fb1f2a4072490b1e16ebcd59fb61467
Don't allow unmounting of /rom via the recovery UI

/rom needs to stay mounted for BCB updating (notably, setting the
reboot-recovery flag) to work correctly.  There's normally no need to
unmount it, so remove the option from the UI entirely.

Change-Id: I26f1da1b1b11772263ab975b79b834b80a4438e3
recovery: fix command-files-on-/boot support for rescue mode

With a rescue mode boot, any command files or postrecoveryboot.sh
extensions would be on the SD card, but by the time postrecoveryboot.sh
runs, /dev/block/by-name/boot already points to eMMC.  Instead, detect
this case and handle it specially in postrecoveryboot.sh.

Change-Id: I17e28ca0cb89abcd12d86f0243ad639766b89c48
configure_vold.sh: use symlink instead of property to detect SD installs

In recovery rescue mode, we want everything set up as if it were an eMMC
install, even though we booted off SD card.  Since the
ro.boot.bootdevice property can't be changed for rescue mode, we need to
use the /dev/block/by-name symlinks to determine whether we want to
configure vold for an SD card install instead.

Change-Id: I2a054f81521f8ba09335adfe5084bb6b1dc6454d
Storage configuration updates

* Limit file size to 4 GB on volumes expected to be FAT32
* Mark eMMC as nonremovable
* Fix typo in the documentation

Change-Id: I2f70004ef74c096465dcce0ba45bff3bc7adef22
Detect and support a combined data/media partition layout

We'd like to move towards a combined data/media partition layout for
future releases of Android -- devices with 1 GB /data will struggle with
ART enabled, while a 1 GB /emmc isn't terribly useful in this day and
age.  To this end, we'd like to introduce the option for users to
repartition their devices during the 4.4/CM11 release cycle.

For this to work, we need to support both traditional (separate /data
and /emmc) and unified layouts.  This requires changes to MountService
to allow configuring storage properties at runtime; with that in place,
we need only detect unified layouts, set the appropriate properties, and
start the FUSE sdcard emulation service when necessary.  (There's the
minor complication that datamedia isn't actually on /data/media for SD
card installs, so we have to detect that case and handle it separately.)

Change-Id: I80d89aac59bcb2018ef7ad4920d87941c3cab63c