MediaScanner: Don't delete entries of secondary storage on shutdown

MediaScanner deletes the entries of secondary storage whenever it
is ejected by the user. However, a shutdown also sends this eject
events. This patch ignores the eject event if the system is being
shutdown.

Change-Id: I0dfe4bd750c563e99b59ad6e9155b241c3228e0d
MediaProvider: fix build

Change-Id: I10f1fbc10443d2c74d5146f5cef5908b8b5dbbb1
MediaScanner: scan any and all volumes that are mounted

Conflicts:
	src/com/android/providers/media/MediaScannerReceiver.java

Change-Id: I3e74814d89f9527e59976bb0c794e6c10700b63c
external storage database fixes (Mike Kasick)

*Commit 1 of 2*
Check external storage volume ID to ensure media is actually mounted.

Programs may request to media scan files (via MediaScannerConnection::scanFile)
before external storage is mounted.  If that happens, MediaProvider creates
an external-ffffffff.db (volume ID -1) database once external storage is
mounted, instead of the one with the expected volume ID.

Later, if android.process.media is killed and respawned, the real external
database (that is, the one corresponding to the actual external storage
volume ID) is attached.  At best, that database contains stale records.
However, in conjunction with another bug (where the LRU database garbage
collector prunes all but one external database), most often a new, empty
database is created.  This results in the sudden disappearance of all
ringtones and media from programs that depend on the media database.

*Commit 2 of 2*
Fix deletion of least-recently-used external databases.

The present external database LRU garbage collector mistakenly includes
SQLite temporary files, including those associated with the internal
database, as distinct external databases.  This leads to a number of
problems, including partial deletion of databases and/or their temporary
files and early deletion of databases before the MAX_EXTERNAL_DATABASES
limit is reached.  In short, the present code works only, and
coincidentally, in a single circumstance: when there is an internal
database and _exactly one_ external database.

This fixes the above problem by removing SQLite temporary files from the
list of candidate databases, and later ensures that all files associated
with a deleted database are deleted as well.

Note, it's quite possible that the actual bug here is in the
android.app.ContextImpl::databaseList and ContextImpl::deleteDatabase
methods, which return SQLite temporary files as part of a context's
"database list" instead of hiding them and handling their deletion
internally.  However, since these methods are part of the Android public
API and used by third-party apps, the present fix is implemented in
MediaProvider only.  Should the Context database API be altered, this fix
will be made redundant but remain unharmful.

Change-Id: I222255babf02b437d9ab7109a5fb1396bd38a9dd

Conflicts:
	src/com/android/providers/media/MediaProvider.java