If they break (due to the reduced space to contain them), it looks
weird.

The Pods' status chart was contrasting the pods with status as "Ready"
with the total number of pods. This meant that if there were pods whose
status was "Succeeded", then they would be counted towards the total
only and give the idea that some pods were not-ready or failed.

This patch fixes that by including the "Ready" and "Succeeded" pods in
the "positive" count of the chart, and dropping the label "Ready" from
the legend as it is no longer exclusively showing that status.

It is useful to know what version of Kubernetes the cluster is running,
so we add a button with the version to the bottom of the sidebar.
When clicked, the button opens a dialog with more information about the
cluster's version.

We need to display the cluster's version in the UI for users to know,
so this patch adds the API method for retrieving that information.

The pods' status label was getting assigned the success color only when
the pod was running. These changes add the success color also when the
status is "Succeeded". Also, now only the "Failed" status gets the red
color.

When getting an item's metrics, if the metrics are not found for some
reason, then we should return the items' use as 0 instead of failing.

This is a temporary fix, as more measures need to be taken when no
metrics are found (like not showing the charts).

The events' color was only green when the reason was "Ready", which
meant that all other event reasons showed up in red, leading to a
perception that the events were related to failures.

These changes fix that by assigning the colors per type of event.
Particularly, if the event type is "Normal" then it gets assigned the
normal color (gray), otherwise it gets assigned the warning color
(orange).

Now that we can set up header actions from the Redux store, we should
add a method to the plugin registry for letting plugins register such
actions.

We want to be able to able to set up header actions (typically icon
buttons) from the MainInfoSection header, so these changes implement
that.

Instead of requiring plugins to import the common components from
relative paths, or to include common libraries like Redux, Material
UI, etc., this patch exposes those libraries in "window" so it's
readily available for all plugins to use.

This patch allows the api.exec command to determine whether the stream
should be reconnected if it fails or exits.

The actual use of it will come in a later commit.

The api.exec was always using the same command, but we may want to
execute a custom command on a pod instead.
This method adds that possibility as an optional command list (keeping
the original command as the default).

The API's stream method always tries to reconnect when a failure occurs
or the stream is closed. This isn't always the desired behavior, so this
patch adds an option to determine that behavior.

The use of it will come in a later commit.

Instead of connecting to an object's logs from the LogViewer, we want
to make this component generic so it can be used to display other logs
or text.
Thus, this patch moves the object logs related logic into another
component defined in the pods/Details view.

The plugin's Registry now allows to register routes. This means that
plugins can set up routes and assign components to them.

This patch adds the possibility of setting up routes from the Redux
store, making it easier to extend the default routes.

These changes add the basic support for frontend plugins.
The current functionality is very limited, it currently allows to set up
Sidebar items only.

The plugins are currently loaded from a "plugin/plugins" folder, if they
are defined in the form: "plugin/plugins/MyPlugin/index.js".

We are implementing frontend plugins, and in order to simplify how they
can add items to the Sidebar component, this patch allows to do that
through the Redux store. i.e. besides the regular Sidebar items, the
component will pull extra items that may be defined in the store.

Instead of having to fetch a route for every Sidebar item entry, it
should also support setting the URL directly from the entry.

This will be useful when we allow plugins to set up Sidebar items and
linking them to a certain URL.

There were a few components with unused variables which resulted in
warnings. This patch prevents those by removing the unused variables.

The filter function was defined, but not assigned to the table.

This patch prevents a warning about an unused variable.

There were warnings about the dependency list for some of the useEffect
hooks, but the suggestions resulted in undesired behavior like too many
reloads, etc.

This suppression is a temporary solution until we take a better look
into the issue.

This patch represents no functional changes, but does surpress some
warnings related to unused imports.

Many places were not using strict equality, and thus it resulted in
lint warnings.

The router already determines the URL and component to render, so
this patch adds a new "sidebar" property to the route specification
allowing to also determine which sidebar item to choose (or whether
to hide the whole sidebar).

Note that the sidebar item can still be selected from any component
by the use of the useSidebarItem hook, but having it in the router
specs is more self-contained and doesn't become a requirement for
creating new components.

This hook can be used by any component to select up their desired
Sidebar item.

It will be used in a coming commit.

Now that we can the state for the sidebar from redux, this patch
replaces the sidebar's logic for selecting the right item.
This simplifies that logic a lot, and allows us also to hide the
sidebar when necessary (e.g. in the login view).

These changes add the state, reducers, and actions for dealing with
UI states (particularly the sidebar at this moment).

The actual use will come in later commits.

This is just a cosmetic change, done for consistency.

The BindingDetails view was assigning the item for the button as an
array of items, which is incorrect (it should be only one single
item).

The title in the SectionHeader was getting shrunk due to how the grid
was built, and thus was wrapping its text even when visually there was
plenty of space for it.

These changes make sure that the title has half of the header's width
to expand, which should be enough.

The data for confimap resources can be null/undefined, in which case
the details view shouldn't attempt to use it.

The buttons were being added to the sections regardless of whether the
user was actually authorized to perform their respective action.

These changes implement the authorization check in each button, only
adding them to the UI in case the user has the needed permissions.

This method will be used to verify whether the user has permissions to
perform given actions on a resource. e.g. delete service accounts.

Since many views will offer the ability to edit a cluster object, this
patch adds a convenience button to manage the visibilty and actions of
the EditorDialog.

It will be used in later commits.

This dialog has a few features that are useful when editing
Kubernetes objects, like the documentation, undoing changes, etc.

Besides the needed dependencies for the editor, react-monaco-editor and
monaco-editor-webpack-plugin, this patch also introduces
the react-app-rewired which replaces the react-app original scripts in
order to allow us to configure things like webpack without ejecting
(losing the "magic config" done by react-app).

The actual use of it will come in later commits.

The way that the tabs are used in Material UI leaves a few things to
the caller. So this new Tabs common component aims that providing a
convenience and quick use of the tabs with the respective content
below them.

The actual use will come at later commits.

Some actions related to buttons need a quick confirmation from the user,
so this patch adds a ConfirmButton that will use a confirmation dialog
when the user clicks it. This is convenient since there will be a number
of places using it soon.