[3006.x] Allow synced modules to override salt extensions

[max-arnold]

What does this PR do?

Swap (3) and (4) in the module search path order, see the Previous Behavior below

Previous Behavior

Current module search path:

1. CLI arg --module-dirs to salt-call
2. Config option TYPE_dirs
3. Setuptools entrypoints
4. Module cache dir (saltutil syncs here)
5. Builtin modules

It doesn't allow a user to override a module that was migrated to extension.

New Behavior

The new priorities and their use-cases:

1. Cli arg is useful for quick development iterations and one-off commands
2. Config option is the same, but set permanently in the master or minion config. Very useful to keep modules between salt upgrades and cache cleans
3. Cache dir is for syncable modules (easy to keep custom mods in the state tree)
4. Entrypoints are for 3rd party extensions
5. Builtin are for core

This follows a logical progression from a more user-controlled to less user-controlled. And allows user-supplied overrides/extends for each level.

If a user has a custom module in _modules that overrides/extends a core module, and the core module was migrated to an extension, the user-supplied override will still work.

Merge requirements satisfied?

• Docs
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

No

[nicholasmhughes]

Core Team, what's the likelihood of allowing a port over to the 3007.x branch so folks can start taking advantage of this sooner?

[max-arnold]

Yeah, it is a good idea to merge this in 3007.x, because the extension migration process is already underway and it might break user-supplied overrides

[s0undt3ch]

Doc build failures are unrelated and getting fixed on separate PRs. Merging.

[max-arnold]

Thank you!