Allow cp functions to derive saltenv from config

[nicholasmhughes]

What does this PR do?

This PR allows the cp module functions to derive saltenv from config if not explicitly set as a keyword argument to the function. See issue for details.

What issues does this PR fix or reference?

Fixes: #61562

Previous Behavior

On minions with a saltenv set:

# /etc/salt/minion.d/saltenv.conf

saltenv: dev

The cp functions would not detect that saltenv and default to "base":

# returns files from the base env (if configured on the master)

salt-call cp.list_master

This often leads to user confusion or surprise because they expect the minion to be "in" a given environment.

New Behavior

The cp functions will now detect the saltenv from the configuration files and use that unless explicitly set:

# returns files from the dev env (if configured as previously shown)

salt-call cp.list_master

# the saltenv can still be overridden

salt-call cp.list_master saltenv=prod

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

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

Commits signed with GPG?

Yes

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.

[nicholasmhughes]

re-run pr-centos-8-x86_64-py3-pytest

[nicholasmhughes]

@MKLeb can you take a look and see if this is a reasonable approach? Thanks!