Unused db tables should be cleaned up between builds that have features disabled.

[andrewtremblay]

Example case :

1. User launches app that has crash reporting enabled.
2. CrashReport manager creates "crashreport" table in database, maybe generates a few crash reports.
3. User launches app that has does not include crash reporting code.
4. database will still have the "crashreport" table with no crashreport code

Problems that this will cause:

• Immortal data in the database.
• Potential collisions with other features that don't expect that table to exist.
• Murky migrations and app updates.

Proposed solution: Tracking all the enabled features (and the tables dependent to them) in the current and last build, similar to how we track the AppBladeKeys.plist file (in the keychain), and then blowing away the tables that we know are linked to specific features on app update first-launch.

[andrewtremblay]

Bonus Challenge How to handle something more ubiquitous like the Custom Parameters function?

[andrewtremblay]

This is solved in the sdk rewrite branch. Bonus challenge included.