Implement cache clear threshold (in days)

[aaronols]

What does this PR do?

• Allow for clearing all files in cache directory older than a certain threshold date (specified in days relative to the current datetime).
• Implemented similar to saltutil.clear_job_cache .
• Add integration test for the new functionality.

example call: salt '*' saltutil.clear_cache days=7

What issues does this PR fix or reference?

At some of our development systems, the salt minions kept filling up the filesystem with nightly build artifacts.
This pull request modifies the saltutil.clear_cache function to accept an optional threshold time when clearing files from the cache directory.

Previous Behavior

All files in the cache folder were deleted.

New Behavior

Only cached files older than the (optional) threshold are deleted.
Specifying no explicit threshold defaults to the old behaviour.

Tests written?

Yes

Commits signed with GPG?

Yes

[dwoz]

@aaronols Can you please resolve the linter issue?

[aaronols]

@aaronols Can you please resolve the linter issue?

All linting issues in new code contributed in this merge request have already been resolved.

The linting issue
tests/integration/modules/test_saltutil.py:274: [W8606(pep8-reserved-keywords), ] PEP8 W606: 'async' and 'await' are reserved keywords starting with Python 3.7
is in the test SaltUtilSyncPillarTest.test_pillar_refresh_sync(). The test was commited by Alexander Fischer in commit 903d777.

My assumption would be that quoting the offending keywords in the test will mitigate the linter issue.
However my knowledge of the internal workings of Python and Saltstack is not deep enough to accurately gauge whether this change will or will not have any unintended side effects.
The use of the async keyword as a parameter might also affect the syntax for the commandline call for the refresh_pillar function itself when running on Python 3.7 (i.e. require escaped quotes to be passed from the shell to python like so: salt '*' saltutil.refresh_pillar \"async\"=False ).

[aaronols]

I just realized the issue has been fixed yesterday in 37782b5.
I'll rebase my branch right away.