Add support of running general Ansible modules on EosHost

[wangxin]

Description of PR

Summary:
Fixes # (issue)
The EOS hosts support two types of command line interface:

1. Linux shell
2. EOS shell

Currently the EosHost class can only support running eos_* ansible modules. This change is to add the support of running general Ansible modules that can only be executed under Linux shell.

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• Test case(new/improvement)

Approach

How did you do it?

Improved the EosHost class defined in tests/common/devices.py to make it accepts two sets of credential:

1. The first set of credential exposes the EOS CLI interface. When use this set of credential, we use ansible_connection network_cli.
2. The second set of credential exposes the linux shell of EOS. When use this set of credential, we use ansible_connection ssh.

If name of the ansible module to be executed on EOS hosts starts with "eos_", then use ansible_connection network_cli to run the module. Otherwise, use ansible_connection ssh to run the module.

How did you verify/test it?

Use a simple script to run both eos_* ansible module and general ansible modules on the EOS hosts and fanout hosts.

For this PR to work, please add your own fanout credentials in the ansible variable files. For example, you can add a secrets.yml file under ansible/group_vars/all or ansible/group_vars/sonic. The fanout credentials can be defined in it, for example:

fanout_admin_user: <your_own_user>
fanout_admin_password: <your_own_password>
fanout_root_user: <your_own_root_user>
fanout_root_password: <your_own_root_password>

Credential set fanout_admin_user/fanout_admin_password should expose the EOS CLI interface. Credential set fanout_root_user/fanout_root_password should expose the Linux CLI shell.

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[yxieca]

Should this be getattribute? I think you want to setup credential for all methods, right?

Did you try to call both EOS and Linux method from a same instance?

[Blueve]

I think the idea here is create NetworkCli based host if user call eos module and create LinuxShell based host if user call other module.
The judgement happens when invoking a module because we couldn't keep two types hosts in a single instance and that's why Xin use getattr.
The only overhead is we need to override extra-var and create a host every time when calling a module.

[wangxin]

Thanks @Blueve for the explanation.
@yxieca According to https://stackoverflow.com/questions/3278077/difference-between-getattr-vs-getattribute:

A key difference between getattr and getattribute is that getattr is only invoked if the attribute wasn't found the usual ways.

When an attribute is not found on the EosHost or FanoutHost instance, the getattr will try to get a function for running the ansible module. This is the key technique for us to invoke ansible module using format like fanouthost.<ansible_module_name>(*args, **kwargs) or eoshost.<ansible_module_name>(*args, **kwargs)

Here the ansible module can a EOS module like eos_command, eos_config, or a regular module like command, shell, etc.

Yes, I have tested that both EOS and Linux method can be called from a same instance.

To support this, the EosHost need two sets of credential. But the credential for running Linux methods is optional.