Enhance the way we detect the cached page for lcp beacon script

[wordpressfan]

Before submitting an issue please check that you’ve completed the following steps:

• Made sure you’re on the latest version Yes
• Used the search feature to ensure that the bug hasn’t been reported before Yes

Describe the bug
Based on this PR: #6610

We agreed to merge it as it is and open another issue to mention the cases we need to handle to enhance this PR's code.

• We can see in some cases we don't serve cache files mainly as a compatibility with some hosting companies so the cache is served from the hosting company not from our side, for this case we may consider clearing the page cache for the page that its lcp row was updated/created.
• When the constant WP_ROCKET_WHITE_LABEL_FOOTPRINT is there we still add the Debug: cached here and we search for it in the new beacon here So we are fine here
• @MathieuLamiot suggested to use the following strings instead of Debug: cached :

'<!-- Optimized for great performance'
OR
'<!-- This website is like a Rocket, isn't it? Performance optimized by '

• Another suggestion is to add a class name or data attribute to any element (html, body, ...etc.) inside the cache file and use it, but again this will work only when we serve our cache (Check first point)

Additional context
Add any other context about the problem here.

Acceptance Criteria (for WP Media team use only)
Clear instructions for developers, to be added before the grooming

[MathieuLamiot]

@jeawhanlee mentioned here that sometimes Debug: cache is not present. This is why I suggested instead:

 '<!-- Optimized for great performance'
OR
'<!-- This website is like a Rocket, isn't it? Performance optimized by '

I don't know in which case this happens though. Maybe @jeawhanlee can explain? But there is a condition so I guess it can happen that Debug: cached is not there:

if ( ! empty( $time ) ) {
     $footprint .= ' - Debug: cached@' . $time;
}

[remyperona]

What are the expectations and acceptance criterias for this issue?

[MathieuLamiot]

@wp-media/product I think this issue would benefit clear use-cases and ACs as I see it is planned for 3.16.4

[piotrbak]

@MathieuLamiot while looking into this issue it doesn't seem to be a quick win. I thought we're not covering the whitelabel scenario but it's the case already. I don't think we'll have an easy solution here to cover the 3rd-party cache.