Add upgrade function to remove old/unused tables

I committed first drafts of upgrade path to 7.x branch, but haven't tried it yet. Testing is welcome.

Working off head 7.x-1.x branch. Getting this error:

og_mailinglist module

Update #7000
Failed: DatabaseSchemaObjectDoesNotExistException: Cannot rename og_mailinglist_thread to og_mailinglist_thread_subscription: table og_mailinglist_thread doesn't exist. in DatabaseSchema_mysql->renameTable() (line 304 of /srv/www/ania.org/public_html/includes/database/mysql/schema.inc).

tommyvyo, this is strange, that you don't have og_mailinglist_thread table. I think you already have og_mailinglist_thread_subscription table (since you didn't upgrade from 6.x but this is a fresh install). I think I need to make the upgrade function only apply when there is og_mailinglist_thread table present.

Unfortunately writing group_email prefixes to fields doesn't work yet, that code (7001) probably would be good if it ran after running og_migrate, but not that early in the cycle.

I fixed the remaining issues with the upgrade path, now for me it works fine.

As a sidenote, since I use node_save() to update group nodes, these all get "updated" flags all set. There might be other ways to set the field without touching the node, but this seems to be the safest way. I hope this is not a problem for you.

The code doesn't delete og_mailinglist table, one could do so all by himself when he has upgraded and is sure that the data is safe.

It seems that I should have introduced database changes together with update functions. Now everybody who installed d7 version before now, will get an error while running update.php about missing table "og_mailinglist_thread". Please just update the system table in the database and set schema_version for name = og_mailinglist to be 7001.

Had this issue. Fix in #4 identified the solution, though should it not be, "Please just update the system table in the database and set schema_version for name = og_mailinglist to be 7000"? You presumably don't want to skip update 7001, which is what the original advice would do, right?

Right, babbage. At the time of writing this I had just added update functions (these are to upgrade from 6.x) and the only obvious reason I saw was that this module was installed (on new 7.x installation) before these functions were present and therefore there was no need to run these update functions. But this should affect no more than a few people.

For future reference, everyone do as babbage says in #6. And if you can locate any problems why upgrading failed for you, please file a report.