Instead of forwarding anything that comes to the backend to the proxy,
we should do it instead with a dedicated prefix, so we can use the
root enpoint for other functions later (like adding a static server).

We should allow users to see the definitions of the objects created for
every CRD, so these changes add a read-only view of those.

We need a way to show a resource's definition without using the edit
function (as it may not be editable). For that purpose, these changes
make the EditorDialog behave as read-only if the onSave property is
passed as null, and add a new ViewDialog component just to conveniently
use the mentioned editor in that way.

The actual use will come in a future commit.

When editing an item, or object, the EditorDialog should be rebuilt if
its item is changed (externally) and there are no changes made by the
user.

This patch adds basic support for listing Custom Resource Definitions
and showing their details. It is still not possible to update/delete,
nor showing their objects' details yet (that will come later).

We need to be able to add support for CRDs, this is the first step.

This column is not always present in the conditions being shown, and
thus should be made optional.

When getting the version in the Sidebar, if the user is not yet logged
in, then the "unauthorized" (401) error happens and it was not getting
caught.

These changes prevent that error by catching it.

The plugin folder shouldn't be tracked in git but it's nice to have it
there.

The overview of the workload items lists a number of cluster objects.
If there was more than one call to the listing callback (i.e. new
objects to be listed), then it would add those to the list while
keeping the existing ones; meaning it could end up in either outdated
objects in the list and duplicated ones.

This patch fixes that by always setting only the objects being listed,
i.e. not keeping the existing ones from previous calls.

It was mistakenly duplicated.

Instead of having a dedicated details view component, we can instead
use the workload's generic one, as there's nothing particular about
the former at the moment.

These details are common to the workload controllers, so we add them
to the workload details.

This component should be reused by other workload controller types,
so we move it to the Resource module instead.

The ConditionsTable component was considering that the lastUpdateTime
and the reason were always available, so when these fields weren't, a
NaN was displayed.

These changes prevent that by using a "-" for that value instead. This
is a quick fix, as in the future we should likely just remove the whole
column from the table.

This component will be used to display the containers' information when
representing several objects.

We should be able to use this component to show only the values, so
these changes add that possibility with a new "showKeys" propoerty.

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.