Implementation of caching functionality for setup-go action

[IvanZosimov]

In the scope of this pull request, the possibility of caching go dependency files and compiler's build outputs was added. Such input parameters as cache and cache-dependency-path were added.

For now, cache input will accept the following values:

true - enable caching for go dependency files and build outputs
false - disable caching for go dependency files and build outputs (default value)

cache-dependency-path input is used to specify the path to a dependency file - go.sum

Description
Action will try to search go.sum file in the repository root or in any other location which is specified in cache-dependency-path input and throw an error if no one is found. The hash of the found file will be used as a cache key ( the same approach as actions/cache recommends). The following key cache will be used: ${{ runner.os }}-go${{ go-version }}-${{ hashFiles('<go.sum-path>') }}

Examples of use-cases:

• cache input only

steps:
- uses: actions/checkout@v3
- uses: actions/setup-go@v3
  with:
    go-version: '18'
    cache: true

• cache along with cache-dependency-path

steps:
- uses: actions/checkout@v3
- uses: actions/setup-go@v3
 with:
   go-version: '18'
   cache: true
   cache-dependency-path: **/go.sum

Linked ADR: #217

Note:
It's not breaking change because it requires an additional field and nothing changes by default.

What's done:

• Implementation of go dependency files and compiler's build outputs caching
• Adding unit tests for caching implementation
• Updating documentation
• Updating licenses

[dmitry-shibanov]

No cache folders exist on disk -> 'There are no cache folders on the disk'

[IvanZosimov]

Solved, review again, please.

[dmitry-shibanov]

Do we need async here ?

[IvanZosimov]

Solved, review again, please.

[brcrista]

I think it would be great to use a standard format for cache keys.

• For Node, it looks like: node-cache-${platform}-${packageManager}-${fileHash}
• For Python / Pip, it looks like ${this.CACHE_KEY_PREFIX}-${process.env['RUNNER_OS']}-python-${this.pythonVersion}-${this.packageManager}-${hash}

Now I know those aren't the same, but I think we should follow one or the other so we don't drift so much. That will help if we're ever able to consolidate the setup- caching logic in some package.

[brcrista]

It seems like the caching implementation has a lot in common with other setup- actions. Many of the functions are similar to those used in setup-node, for example.

I think it would be much better either to put these in @actions/cache. Or we could create a shared "@actions/setup" package that encapsulates all the common logic among setup- actions. That will make sure all setup- actions behave consistently.