refactor: extract ResponseCache class for Web Page Caching

[kenjis]

Description

• extract ResponseCache class
  • to make it easier to extend the page caching
• fix incorrect type definitons for request

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[iRedds]

The service returns the same object. Does it make sense to create an additional property?

[iRedds]

I'd like to suggest a change.

1. Renaming a class and methods.

• rename class PageCache to ResponseCache
• rename method cachePage to make
• rename method getCachedResponse to get

2. Move the CodeIgniter::$cacheTTL property to the new page caching class. That is, all functionality will be processed by one class.
   The Controller::cachePage() method could then look like this.

protected function cachePage(int $time)
{
    Services::pagecache()->ttl($time);
}

3. I don't know if it makes sense for the generateCacheKey method to be public.

[kenjis]

Thank you for your comment.

What about the namespace? Should be in CodeIgniter\HTTP?

[iRedds]

What about the namespace? Should be in CodeIgniter\HTTP?

I think the namespace should stay the same.

[iRedds]

Thank you for considering my suggestion, but in this snippet, I meant a slightly different approach.

Suggested change

	if ($this->pageCache->getTtl() > 0) {
	$this->pageCache->make($this->request, $this->response);
	}
	$this->pageCache->make($this->request, $this->response);

and then the decision on the need to cache the Response is made by the caching class.

    public function make($request, ResponseInterface $response): bool
    {
        if ($this->ttl === 0) {
            return ; // bool (false or true)
        }

This is how I see the implementation, but I don't know if my approach is correct or not.

[kenjis]

If $ttl is 0, there is no need to cache it, so that seems a little better.

Done.

[iRedds]

I have a little doubt, but it seems to me that there is no point in caching the response for the CLI.

It seems to me that the current documentation is sufficient, since in fact nothing has changed for the end developer.

[kenjis]

Added changelog.

[kenjis]

I have a little doubt, but it seems to me that there is no point in caching the response for the CLI.

Indeed, I am not sure if there is a use case.
However, it is a feature that currently exists, so it cannot be removed all of the sudden.