[WIP] In progress -  multiple endpoints per provider feature

Below is an overview that I hope will help you understand the code changes that make up this new feature.  Please focus on overall design, keep it high level. Once it is working I will sweep through and make improvements.

General overview:

We now have a class called EMS_Connection. Which kind of “sits between” the ExtManagementSytem and the Authentication classes.
This PR excludes ALL changes to the UI, but I envision we will have a UI frame for each EMS_Connection encompassing at least: 
IP
port
hostname
provider_component eg “refresh” or “events”
existing User Credentials box

Each ExtManagementSystem will have one or more EMS_Connection(s) with the ems_id as the foreign key.
The EMS_Connection will have one or more Authentications with the ems_connection id as the foreign key.

The EMS_Connection includes the AuthenticationMixin making it easy for it to take care of the many methods we already have in place for saving and checking credentials.

A couple of things:

1) The EMS still takes care of the validate_credentials and connect methods but now depends on the credentials being passed into each method in the options hash as opposed to being directly accessible from the EMS itself. (remember the validate_credentials only has access to variables stored in memory, not the database.)

2) Workers
 - In order for the workers to start up we check if the EMS has valid credentials configured (per_ems_worker_mixin)
 After the workers have been initialized (ems_refresh_core_worker and ems_refresher_worker) we check the credentials of the EMS again, like this:

@ems.authentication_check

The new approach is to get a handle on the EMS_Connection as per the example below:
@ems.ems_connections.find_by_provider_component("refresh").authentication_check

Once I have everything working I will see if I can improve on this without passing in the string, maybe create a new method in the ext_management_system class which uses the class name instead, not sure.
I follow this approach in other places too eg the refresher parsers.
I recommend doing the schema changes and data migration as separate
migrations.  You will probably need 3 migrations but that's ok.
On Nov 13, 2014 9:35 AM, "Greg Blomquist" <notifications@github.com> wrote:

> In vmdb/db/migrate/20141006200403_create_ems_connections.rb:
>
> > @@ -0,0 +1,13 @@
> > +class CreateEmsConnections < ActiveRecord::Migration
>
> My previous comment didn't go far enough. Here's what the migration really
> needs to do:
>
>    1. Create the new ems_connections table.
>    2. Create appropriate records in the ems_connections table.
>    3. Remove the ipaddress, hostname, and port columns from the
>    ext_management_systems table.
>
> And, this all needs to be able to be rolled back. So, I think it needs to
> be in up and down methods, instead of change.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/ManageIQ/manageiq/pull/1037/files#r20293730>.
>