Provide local task for editing current dashboard layout

Hi,

Thank you for your great work here. Tested both Tugboat environments, and I would go for the Local Action based approach.

It looks cleaner to me. The "Edit Layout" local task at the same level can be confusing and it requires the extra redirect you mentioned.

In case we want to follow the local tasks path, we might try to add the parent_id property to show it in a second level, like in /admin/structure/block.

Agree that nested local tasks can be problematic, so let's put them apart for now.

Attaching patch following a custom local task class approach instead of the intermediate controller. This approach could be useful as well if we need to move to local tasks in the future.

1. +++ b/src/DashboardManager.php
   @@ -0,0 +1,66 @@
   +  /**
   +   * The current user account.
   +   *
   +   * @var \Drupal\Core\Session\AccountInterface
   +   */
   +  protected $currentUser;
   +
   +  /**
   +   * The entity type manager.
   +   *
   +   * @var \Drupal\Core\Entity\EntityTypeManagerInterface
   +   */
   +  protected $entityTypeManager;
   ...
   +  public function __construct(AccountInterface $current_user, EntityTypeManagerInterface $entity_type_manager) {
   

   - public function __construct(AccountInterface $current_user, EntityTypeManagerInterface $entity_type_manager) {
   +public function __construct(protected AccountInterface $current_user, protected EntityTypeManagerInterface $entity_type_manager) {
   

2. +++ b/src/DashboardManager.php
   @@ -0,0 +1,66 @@
   +   * @return \Drupal\dashboard\DashboardInterface|null
   +   *   The dashboard to be used if available, NULL otherwise.
   ...
   +  public function getDefaultDashboard(AccountInterface $account = NULL) {
   

   could return type ?DashboardInterface

3. +++ b/src/Plugin/Menu/LocalAction/DashboardLocalAction.php
   @@ -0,0 +1,73 @@
   +   * The dashboard manager.
   +   *
   +   * @var \Drupal\dashboard\DashboardManager
   +   */
   +  protected $dashboardManager;
   ...
   +    DashboardManager $dashboard_manager
   

   could be moved to protected DashboardManager $dashboard_manager in constructor

Back to Needs Review once #3348617 is already merged.

Thank you for your review @andypost. I'm fine these PHP 8.1 style code changes, but I don't know what's the policy about it in Drupal core right now. Reviewed some modules and apparently they're not not following it yet. In any case I would do it at once for the whole module at some point instead of following it in specific places and other don't.

Core started to adopt constructor promotions already, it helps to minimize boilerplate for properties.

Sounds like a plan!

Thank you for checking it.