cp.get_url: fix dest=None behaviour with salt:// URL

[vutny]

What does this PR do?

It makes cp.get_url function behave according to the docstring.

What issues does this PR fix or reference?

The issue is following: the function doc says that passing dest=None will return file contents, but this doesn't work with salt:// URL. See example below.

Previous Behavior

# salt-call cp.get_url salt://files/test None
local:
    /var/cache/salt/minion/files/base/files/test

New Behavior

# salt-call cp.get_url salt://files/test None
local:
    This is a test

Tests written?

Yes! Added integration tests.

[rallytime]

@vutny It looks like some integration tests that are related to this change are failing. Can you take a look?

[vutny]

Thanks @rallytime, that was a silly typo. Fixed now.

[cachedout]

It looks like this just applies to the salt:// schema. Should we extend this to all the protocols?

[vutny]

@cachedout What do you mean exactly? dest=None should work with all supported protocols. I can add another test for that.

[cachedout]

I'm referring to your changes in the fileclient. It looks like they are made under the block for salt://. I'm wondering if, for example, we'll have a problem if somebody uses cp.get_url with, say, swift:// and dest=None expecting that it will behave as it does with a URI beginning with salt://. Does that help explain?

[vutny]

Ah! I got it. There's special no_cache parameter which passed to the get_url function in the fileclient module. Looks like it is only recognized by the code block which handles http[s]:// scheme.

I guess the only thing we could do for now is to document the status quo. I've added a note to the docstring.

Is that OK?

[vutny]

Meanwhile, I've added support forfile:// URLs with dest=None and written couple of tests. The docstring has been updated accordingly.

[cachedout]

Looks good. Thanks as always, @vutny