Add dblog-specific permissions to control access to dblog routes

Adding a patch for 10.3.x (that's our current branch) in case anyone else can use it.

Updated the patch as I missed a couple uses of the 'access site reports' permission.

One more new version of the patch. I forgot to add dblog.permissions.yml to the previous versions.

@smustgrave Thank you for the suggestions and I apologize it took me so long to circle back to this.

Here's a summary of the latest changes:

• Added an update hook to update the Watchdog view if it uses the default permissions (I assume we want to leave it alone if the site owner has customized it).
• Added test coverage for the update hook (the test coverage checks the permission on the Watchdog view before and after the update).
• Added test coverage to check if a user with the 'access site reports' permission can see the Reports menu item in the admin toolbar.
• Added test coverage to check if a user with the 'access dblog reports' permission can access the Recent log messages page.

This is the first time I've written these types of tests, so please double-check them and let me know if anything is missing or incorrect.

Also, I haven't addressed the test failures yet. I hope to do so within the next couple days.

@smustgrave I finally got the tests completed and all are now passing. Would you take another look at it and let me know if any other changes need to be made?

@dagmar Thank you for the catches! I've added the access dblog reports permission in the other locations where the access site reports was already being used, with one exception:

In modules/migrate_drupal_ui/tests/src/Functional/MigrateUpgradeExecuteTestBase.php: The user in this test is the root user (uid 1), so should implicitly have all permissions. With that in mind there's no need to set the specific permission.

@dagmar Thank you for pointing these out. I believe I've fixed all of the failed tests at this point, but please review the results and let me know if I missed anything.

Been picking away at this and I'm at the point where I need some help with the tests.

The only remaining PHPUnit test issues are related to the issue below. I checked the default config for the Watchdog table in views.view.watchdog.yml and found that there's no default class provided. At this point I think fixing this is outside the scope of this issue, but I'm more than happy to fix it if anyone feels it should be included.

The update to add a default table CSS class for view "watchdog" is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. Profile, module and theme provided configuration should be updated. See <a href="https://www.drupal.org/node/3499943">https://www.drupal.org/node/3499943</a>.

The PHPUnit Functional JavaScript errors are also unrelated:

Behat\Mink\Exception\ExpectationException: The string "Added text format ckeditor5." was not found anywhere in the HTML response of the current page.

As for Nightwatch, the error is below. I don't believe it's related to the changes in this issue:

An error occurred while running .click() command on <input[name="i5byg6bay[administer modules]"]>: element click intercepted: Element <input class="rid-i5byg6bay js-rid-i5byg6bay form-checkbox" data-drupal-selector="edit-i5byg6bay-administer-modules" type="checkbox" id="edit-i5byg6bay-administer-modules" name="i5byg6bay[administer modules]" value="1"> is not clickable at point (674, 52). Other element would receive the click: <th class="checkbox">...</th>

I'm happy to continue digging into the test results, but at this point I don't feel like there's much more I can do.

@dagmar I finally had a chance to take a look at your last suggestion. I haven't used this method to update config before. Would you mind checking my logic to make sure I'm on the right track?

Convert dblog_update_112002 to the following, which would be in dblog.post_update.php:

/**
 * Update view permissions from 'access site reports' to 'access dblog reports'.
 */
function dblog_update_permissions(ViewEntityInterface $view): void {
  $changed = FALSE;
  $displays = $view->get('display');
  
  foreach ($displays as &$display) {
    if (
      isset($display['access']['options']['perm'])
      && $display['access']['options']['perm'] === 'access site reports'
    ) {
      $changed = TRUE;
      $display['access']['options']['perm'] = 'access dblog reports';
    }
  }
  
  if ($changed) {
    $view->set('display', $displays);
  }
}

@here Sorry for all the git spam! I rebased the issue branch against 11.3.x and resolved a bunch of issues from that. I'll see about fixing the remaining test issues so hopefully this can start moving forward again.