Not all toolbar items are tabs: Toolbar's "activeTab" handling interferes with active-link.js

Problem/Motivation

If you customize the toolbar (for a particular site or a distribution), and the first toolbar item is not a tab, then toolbar.js will always mark the first toolbar item as being active.

hook_toolbar() (see core/modules/toolbar/toolbar.api.php) speaks of toolbar items. But then core/modules/toolbar/templates/toolbar.html.twig marks every toolbar item as a tab:

    {% for key, tab in tabs %}
      {% set tray = trays[key] %}
      <div{{ tab.attributes.addClass('toolbar-tab') }}>

This is wrong.

Worse, core/modules/toolbar/js/toolbar.js then does this:

        // If the toolbar's orientation is horizontal and no active tab is
        // defined then show the tray of the first toolbar tab by default (but
        // not the first 'Home' toolbar tab).
        if (Drupal.toolbar.models.toolbarModel.get('orientation') === 'horizontal'&& Drupal.toolbar.models.toolbarModel.get('activeTab') === null) {
          Drupal.toolbar.models.toolbarModel.set({
            activeTab: $('.toolbar-bar .toolbar-tab:not(.home-toolbar-tab) a').get(0)
          });
        }

This means that by default, if there is no active tab, it will automatically set the first toolbar item as active. Even if it's just a link, and not actually a tab.

This means that if the first toolbar item is a link, it is automatically marked as active, and will continue to be so until the first "actual" tab (with a tray, e.g. the "user" tab+tray) is clicked. But until you do, that means the first toolbar item (a link) will remain active, even while you click other toolbar items that are links, to navigate around. This is super confusing behavior.

Proposed resolution

1. Better distinguish between "tab" items and "link" items.
2. Stop assuming the default toolbar in the codebase.

Remaining tasks

User interface changes

API changes

Data model changes