Support redirect_404 for 404 request monitoring

Committed that. Would be nice if someone would look into those test fails because now you will have to always manually request a test.

1. +++ b/src/Plugin/monitoring/SensorPlugin/Monitoring404SensorPlugin.php
   @@ -0,0 +1,113 @@
   + *
   + * @SensorPlugin(
   + *   id = "monitoring_404",
   + *   provider = "redirect_404",
   + *   label = @Translation("Monitoring 404"),
   

   just like the other is called Dblog404, this should be called redirect_404, the id possibly monitoring_redirect_404, label should also clarify that this the redirect_404 version.

2. +++ b/src/Plugin/monitoring/SensorPlugin/Monitoring404SensorPlugin.php
   @@ -0,0 +1,113 @@
   +   */
   +  public function getAggregateQuery() {
   +    /* @var \Drupal\Core\Database\Connection $database */
   +    $database = $this->getService('database');
   +    // Get aggregate query for the table.
   +    $query = $database->select($this->sensorConfig->getSetting('table'));
   

   count of just one record does't make sense. just select count as records_count or what it is with addField(). And that should be possibly by just overridig the aggregate method called by the parent.

3. +++ b/src/Plugin/monitoring/SensorPlugin/Monitoring404SensorPlugin.php
   @@ -0,0 +1,113 @@
   +    $query->orderBy('count', 'DESC');
   +    $query->range(0, 1);
   +    return $query;
   

   additionally select the path field and display that in the message like the other 404 sensor

4. +++ b/src/Plugin/monitoring/SensorPlugin/Monitoring404SensorPlugin.php
   @@ -0,0 +1,113 @@
   +    $query->orderBy('count', 'DESC');
   +    $query->condition('resolved', 0);
   +    $query->range(0, 10);
   +    return $query;
   

   the aggregate also needs the check on resolve. you could also put that in settigs, then both should respect it.

5. +++ b/src/Plugin/monitoring/SensorPlugin/Monitoring404SensorPlugin.php
   @@ -0,0 +1,113 @@
   +    parent::runSensor($result);
   +    $query = $this->getQuery();
   +    $this->executedQuery = $query->execute();
   +    $this->fetchedObject = $this->executedQuery->fetchObject();
   +    $count = 0;
   +    if (!empty($this->fetchedObject->count)) {
   +      $count = $this->fetchedObject->count;
   +    }
   +    $result->setValue($count);
   

   if you select it as the right field name, then the parent does this for you, and you just need exactly the same as the other 404 for the path.

6. +++ b/src/Tests/Monitoring404SensorPluginTest.php
   @@ -0,0 +1,42 @@
   +    ]);
   +    $this->drupalLogin($test_user);
   +    $this->drupalGet('/admin/config/system/monitoring/sensors');
   +    $this->assertText('Monitoring 404');
   +    $this->drupalGet('/admin/config/system/monitoring/sensors/non-existing-sensor');
   +    $this->drupalGet('/admin/config/system/monitoring/sensors/non-existing-sensor');
   +    $this->drupalGet('/admin/reports/monitoring/sensors/monitoring_404');
   +    $this->assertText('/admin/config/system/monitoring/sensors/non-existing-sensor');
   +    $this->assertText('2 404 requests');
   

   extend with checking the patch in the message as well.

   I would actually recommend to insert the rows directly into the database and making this a kernel test. redirect_404 has such a test to test purging of data, you can do it in a similar way. We want records older than one day, records that are resolved and multiple with different counts to make sure we get the right now and test all our coditions.

   Also installing the redirect_404 module can be done in the property now.

+++ b/src/Plugin/monitoring/SensorPlugin/Redirect404SensorPlugin.php
@@ -0,0 +1,98 @@
+  public function runSensor(SensorResultInterface $result) {
+    parent::runSensor($result);
+    if (!empty($this->fetchedObject) && !empty($this->fetchedObject->path)) {
+      $result->addStatusMessage($_SERVER['REQUEST_SCHEME'] . '://' . $_SERVER['HTTP_HOST'] . $this->fetchedObject->path);
+    }

just the path is enough, we don't need this, it would be wrong anyway on drush and so on.

Nice, tested that this is created on rebuilding the sensor list and committed.