Add cache updating independently from Indexer

[saneery]

Relates to #2583

Motivation

Blocks, Transactions and BlockNumber caches are updated by Indexer, but when Indexer runs separately from WebApp, caches aren't updated. So I added TTL for this caches to updating them without Indexer.

Checklist for your PR

• I added an entry to CHANGELOG.md with this PR
• If I added new functionality, I added tests covering it.
• If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
• I checked whether I should update the docs and did so if necessary
• If I added/changed/removed ENV var, I should update the list of env vars in https://github.com/poanetwork/blockscout/blob/master/docs/env-variables.md to reflect changes in the table here https://poanetwork.github.io/blockscout/#/env-variables?id=blockscout-env-variables. I've set master in the Version column.
• If I add new indices into DB, I checked, that they don't redundant with PGHero or other tools

[coveralls]

Pull Request Test Coverage Report for Build c2073d23-ebfb-4963-b80e-0f62bb5fd7e8

• 0 of 1 (0.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 78.637%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
apps/explorer/lib/explorer/chain/ordered_cache.ex	0	1	0.0%

Totals
Change from base Build 40fa414a-f7e7-4e58-b60a-3f6392fa16cc:	0.0%
Covered Lines:	5146
Relevant Lines:	6544

---

💛 - Coveralls

[pasqu4le]

I am ok with the changes, I just want to point out that I am preparing a PR with another generic cache implementation (I put it on hold but I'm going to fix it now): #2581
Regarding BlockNumber it has some changes in common with this PR and I'll integrate the ones that are not if this gets merged first.
Also it takes care of the first comment by @ayrat555 (the child_spec definition)

[pasqu4le]

@saneery I was thinking about this PR and there is a problem to be considered for ordered caches.

The thing is that setting a :ttl_check_interval is not enough. Their logic is based on an indexing list stored in the cache itself that needs to be updated when the expired element is deleted.
This can be done by setting a :callback option and I started making it (#2628), but I realized this would add a considerable costs in the case where the cache gets updated by the indexer.

So in the end a change is necessary here, the way I would implement it by invalidating the entire cache after a certain time, starting by changing the macro to only set an expiration on the ids_list_key().

Alternatively this could be implemented as an element-based expiration like this:

• add a public function remove_from_index(key) to the ordered cache macro (the implementation can be basically what is inside this function I was writing)
• add a :callback option to both caches to use it when DISABLE_INDEXER is used

This however would be less efficient I fear, because the caches are usually filled entirely in one call (when the indexer is not used)

What do you think?
I don't know if my explanation is clear enough, if you want I can add a commit to this PR myself.

[saneery]

if you want I can add a commit to this PR myself.

@pasqu4le please feel free

[pasqu4le]

@saneery sorry if I kept you waiting. I pushed 2 commits on top of this branch, the first one solves the issue with removing the expired elements from the caches and the second one fixes my comment about merging options from the application environment.

I kept them separated because I did not know what your answer was regarding the second one.

[pasqu4le]

@vbaranov @ayrat555 I have rebased/updated/fixed the PR and it should now be ready to be used. Please review it when you can.

[vbaranov]

It works fine now 👍 with disabled indexer