Migrate with cleared schema cache

[jrafanie]

Alternative to #398

Wrap each migration with a clearing of the schema cache to ensure the
schema/column information is not cached. Since migrations very often
change schema, these caches are likely to get busted.

Migration authors don't realize they may need to reset the column
information whenever they change the schema so it's often overlooked.
It often doesn't cause a problem, until it does:

20180424141617_azure_backslash_to_forward_slash.rb
 - loads stub: class OrchestrationStack < ActiveRecord::Base
 - orchestration_stacks table column information is cached by table name

20181010134649_add_evm_owner_to_orchestration_stacks.rb
 - adds evm_owner, miq_group, tenant references (_id columns)

20181016140921_migrate_orch_stacks_to_have_ownership_concept.rb
 - loads stub: class OrchestrationStack < ActiveRecord::Base
 - uses cached table column information
 - Blows up trying to store bigint into what rails thinks is an integer column:
   stack.update_attributes(:evm_owner_id => user.id, :tenant_id =>
   user.current_tenant.id, :miq_group_id => user.current_group.id)
   '34000000000001 is out of range for ActiveModel::Type::Integer with
   limit 4 bytes'

This commit eliminates the need to reset column information for any of
these migrations as we clear the schema cache for all tables before each
migration.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1732808

[jrafanie]

@Fryguy @carbonin @d-m-u I believe this consolidates all of our ideas into one concept: clear the schema information before running migrate...

[jrafanie]

yay it failed even though it didn't locally... looking...

[jrafanie]

Ok, finally, fixed. The complexities with resetting column information in migration tests are still needed around each example because the migration stub gets reused in tests. I verified this works in migration specs and also with a test database that was raising the 34000000000001 is out of range for ActiveModel::Type::Integer with limit 4 bytes error.

[jrafanie]

@Fryguy please review

[jrafanie]

@carbonin @bdunne I think I addressed all of the concerns. 🍪

[miq-bot]

Checked commit jrafanie@cdfce63 with ruby 2.4.6, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. 🍪

[jrafanie]

Note, I've retested the problematic database down and up using the "reset cache only before migrate" since I previously tested "before and after migrate".

[simaishi]

Ivanchuk backport details:

$ git log -1
commit ed95ecf9b91de89c4de30702d2efc81ba0a5438d
Author: Brandon Dunne <bdunne@redhat.com>
Date:   Wed Aug 7 12:01:45 2019 -0400

    Merge pull request #401 from jrafanie/migrate_with_cleared_schema_cache
    
    Migrate with cleared schema cache
    
    (cherry picked from commit 44bbd51ddb5a8566ebe5c75da4c4175d726e0774)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1732808