Provide context of how checker service is run

I thought I uploaded the patch earlier. Here it is now.

1. +++ b/composer.json
   @@ -11,6 +11,7 @@
   +    "php": "^7.0",
   

   Let's leave this off as long as possible. I'd like to backport as much as possible to D7, so unless we have a very compelling reasons to use PHP 7+, I'd rather remove this version constraint.

2. +++ b/src/ReadinessChecker/Filesystem.php
   @@ -31,21 +31,24 @@ abstract class Filesystem implements ReadinessCheckerInterface {
   +    return $this->doCheck($invoked_from);
   
   +++ b/src/ReadinessChecker/ModifiedCode.php
   @@ -56,7 +56,7 @@ class ModifiedCode implements ReadinessCheckerInterface {
   +  public function run(int $invoked_from) {
   

   I really don't like how the context addition makes the interfaces bleed so much. Can we add a context service, as done here in this patch. But then set the context in the checker manager? And on checkers where it matters, inject the context service to obtain the context?

3. Lastly, could do this in two+ phases? One that adds the context service and then others that builds on its presence? I feel like right now the patch is all over the place and not very focused. Making it hard to review as we have state being injected and all the rest. Let's keep things simple. And build upon things.

I was starting to look into what it would take to implement my suggestions above. And went full circle. What are we trying to solve here?

1. It looks like we want to distinguish PHP_SAPI === 'cli'.
   • Let's just add a checker that stores the last method. And if the last and the current don't match, warn that this can lead to inconsistent test results. We'd want to be careful with wording so that it is clear what and why this could be a problem.
2. It also looks like we want to check if/when cron was last run.
   • For this, we can just add a checker that calls $this->state->get('system.cron_last') and warn if it is over 60 minutes.

Parting thoughts; we need to support manually running updates (via a button) and applying updates (via cron). And we need to be able to turn off cron application of updates so manual is the only option.

Ok, that was a lot of thinking. Does any of this line up with anyone else's thoughts?

I've held off looking into this much more since I posted #5 because I wasn't sure if what I stated had general consensus. Are those bullet points something to consider moving forward?

For cron warning/error, I propose that we adjust core's existing warnings and errors. It already posts errors/warnings when cron hasn't run recently in system.install. Using https://www.drupal.org/docs/8/api/configuration-api/configuration-overri..., we could check existing levels and warn if cron doesn't run at least every X and error if it hasn't run within Y.

Since core currently defaults to 3 hours for running cron, I don't think we want to warn differently on X. The patch in #5 warns on 60 minutes. And maybe we want to double that for Y and error if hasn't run for 6 hours?

That's run time. We should also error if cron is setup to run anything but 3 hours or Never.

Lastly, let's also add a warning and messaging if the PHP_SAPI changes between checker runs.

Going to start work on the PHP_SAPI checker first.

Simple enough. No interdiff.

I've opened #3058250: Cron frequency for the cron execution checking.