include the virtualname in the file name for core modules

[gtmanfred]

What does this PR do?

There is a condition in the loader for salt, where you could end up with finding modules taking forever.

When loading modules, we look at

1. the name of the module is the name of the .py file, if it matches what is being called, we use that one.
2. The name of the module is in the name of the .py file, we then load all of those and check if the virtualname matches, and if it does, we use that one.
3. start from the top, alphabetically, and go down the list of modules, until we find one that has the correct virtualname.

This is usually not a problem, unless you are using some module that hits part 3, and is after esxi.py and possibly vsphere.py because those use the @Depends decorator, which takes longer to run when loading, and can cause it to take a really long time for the lazyloader to load the module you are looking for.

This PR adds a unittest to make sure there are no modules in the core modules of salt that fall into the third category, so that we make sure to optimize loading of salt core modules (3 can still be hit by users custom modules)

Tests written?

Yes

Commits signed with GPG?

Yes

[gtmanfred]

ugh, it only works on py3, i need to fix this for py2 as well.

[gtmanfred]

still need to fix autodoc

[gtmanfred]

@saltstack/team-core can someone look at this?

Thanks,
Daniel

[terminalmage]

Doesn't this file need to be renamed?

[terminalmage]

This will probably break if dson is installed. The first value in the tuple should be either a string or a bool, in this case it's either a module or None.

[dwoz]

@gtmanfred are you able to resolve the conflicts here?

[gtmanfred]

Yeah, I need to do that and fix the tests still, i will try to get to it later today.

[gtmanfred]

Rebase done, waiting on the test suite to run so that I can see what tests need to be fixed.

[gtmanfred]

@dubb-b something is going on with bootstrapping of the tests and possibly nexus.

Thanks,
Daniel

[dubb-b]

@dubb-b something is going on with bootstrapping of the tests and possibly nexus.

Thanks,
Daniel

@gtmanfred looks like more-itertools that CherryPy depends on releases 6.0.0 and we need to pin earlier version for py2. They went py3 only.

[gtmanfred]

@dwoz this should be all ready to go once the tests pass

[gtmanfred]

I squashed the commits so it would be easier to merge forward.

[gtmanfred]

Thanks @dwoz

[cachedout]

Does this need a changelog entry?

[gtmanfred]

Makes sense to me, i will write something for the 2018.3.5 release doc.

[damon-atkins]

Just thought I point out this discussion #30533 on module names.