Don't return a duplicate object from MiqGroup#settings

[carbonin]

Commit c0a662b made the return value of MiqGroup#settings a HashWithIndifferentAccess. Unfortunately, Hash#with_indifferent_access returns a duplicate object.

This behavior breaks callers when they attempt to alter the settings hash in-place, for example:

https://github.com/ManageIQ/manageiq-ui-classic/blob/7d2ef009ac536770b1415ee59fa79c3a01e4d53e/app/controllers/report_controller/menus.rb#L230-L231

This PR changes the #settings method to also set the settings attribute so that it returns the same instance as is set for the group object. Additionally the settings= method had to be changed so that we are consistent with the new type in the column.

This has the same net effect as a data migration and a serialization type change to ActiveSupport::HashWithIndifferentAccess. I'm okay with either route.

/cc @yrudman @skateman

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

[miq-bot]

Checked commits carbonin/manageiq@66f86e4~...57c8d63 with ruby 2.3.3, rubocop 0.47.1, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. 👍

[skateman]

[simaishi]

Gaprindashvili backport details:

$ git log -1
commit d6bba5e266134753b52fea120a41a86a4149e8ae
Author: Gregg Tanzillo <gtanzill@redhat.com>
Date:   Fri Dec 1 06:55:14 2017 -0500

    Merge pull request #16572 from carbonin/group_settings_with_indifferent_access
    
    Don't return a duplicate object from MiqGroup#settings
    (cherry picked from commit 1ff04a9ebc3ea848a9be591fac1685c2384f21bb)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1519858

[bdunne]

The more I think about this, the more I like the migration route. I don't see any reason we can't still get a simple data migration into gaprindashvili for this. Then we can change to serialize :settings, ActiveSupport::HashWithIndifferentAccess and get rid of all of this tech debt. @Fryguy @chrisarcand Any opinions?

[carbonin]

@bdunne Yeah, I was hoping to prompt a discussion and possibly make both PRs to compare approaches.

I should have left this as WIP until I could do that ... sorry about that.

I probably won't have time today, but I think we can still go that route and have the PR which changes the settings serialization class just remove the overrides for the settings setter and getter.

Would also like @imtayadeway 's opinion here, he seemed reluctant to go straight to HWIA in the original patch.