Add ability to use headers from `Vary` as part of cache keys

[skryukov]

The initial problem: we use GitHub API and to save on API limits we want to use HTTP caching, but with the current Faraday::HttpCache::Storage implementation (one cache key per URL) caching of GitHub API endpoints like https://api.github.com/user is impossible since for every request we are fetching an array of all requests for all our users. Limiting the number of cached entries per key from #121 is also not an option in this case.

So, the only way to cache GitHub API for us is implementing different storage strategy. That is what this PR is about.

This PR Introduced a new strategy option to support different cache storage strategies:

• The original strategy was moved from Faraday::HttpCache::Strage to Faraday::HttpCache::Strategies::ByUrl.
• The new Faraday::HttpCache::Strategies::ByVary strategy uses headers from Vary header to generate cache keys. It also uses the index with Vary headers mapped to the request URL.
• Faraday::HttpCache::Strage class was deprecated.

This PR also:

• drops support for Ruby < 2.4
• adds support for Ruby 2.7, 3.0, 3.1
• introduces GitHub Actions
• updates Rubocop

This PR is a successor for #122 Related #112

[garaujodev]

Thanks for the PR ❤️💜💙💛💚🖤

I'll take a look as soon as possible!

[garaujodev]

I'm assuming as maintainer for this gem. For my first releases, and to be in compliance with Semantic Version standards, I intend to be more conservative on releases.

I think that a good idea to reach it, is split this PR into 3 PRs:

• Introduce GitHub Actions and Update Rubocop
• Add support for Ruby 3.0 (I'll release it as a patch version)
• Introduce cache strategy feature (I'll release it as a minor version)

@skryukov what do you think about? Could you split this PR into 3 mentioned PRs?

Please just let me know if you need help to do that.

[skryukov]

@garaujodev sounds fine.

What about support for ruby < 2.4? I believe the gem is still capable of supporting them (not sure about the strategies part though), we only need to downgrade some dev dependencies (including rubocop) to enable the test suite.

But is that worth the headache?

[garaujodev]

@skryukov I was thinking about it, because support for Ruby 2.4 was ended in 2020.

With that, I'm planning to release in this way (Current version: 2.2.0):

• Ruby 3 support and deprecate Ruby 2.4 -> 2.3.0
• Cache strategy -> 2.4.0

So, we can deprecate Ruby 2.4 in the same PR that introduce Ruby 3 support.

[skryukov]

Closing in favor of #128 #129 and #130