Easy to understand and flexible "info" command

[VMois]

Originated in #540 (review) and #540 (comment)

After adding to the "info" command new values, there were a few suggestions on how to improve it:

1. Group values together. The first approach is to group them close to each other, e.g.:

List of available workspaces: /var/reana
Default workspace: /var/reana
List of supported compute backends: kubernetes
Default timeout for Kubernetes jobs: 604800
Maximum timeout for Kubernetes jobs: 1209600
Default memory limit for Kubernetes jobs: 4Gi
Maximum allowed memory limit for Kubernetes jobs: None
Maximum retention period in days for workspace files: None

The second approach can be to group them by categories:

Workspaces
     default: /var/reana
     available: /var/reana, etc.
Compute backends:
     available: kubernetes
Kubernetes backend:
     default job memory: 4Gi
     maximum allowed job memory: None
 ...

2. It is not nice that when, for example, the retention period doesn't exist (we keep files forever), the info command will show None. I suppose the user can deduce what it means but still better to make it explicit. Example:

Maximum retention period in days for workspace files: None
vs
Maximum retention period in days for workspace files: keep forever

But you cannot programmatically deduce the value "keep forever" so maybe, it makes sense for each config to have values. One is programmatic, another one is message/explanation.

3. Adding new values causes schema change, meaning changes need to be propagated to reana-client-go (modify Go code), reana-commons (update OpenAPI), and, technically, reana-client (although Python does not respect OpenAPI sometimes). Adding new values should not require so many changes in the schema. Below is the part of the current OpenAPI schema.

{
  "properties": {
    "compute_backends": {
      "properties": {
        "title": {
          "type": "string"
        },
        "value": {
          "items": {
            "type": "string"
          },
          "type": "array"
        }
      },
      "type": "object"
    },
    "default_kubernetes_jobs_timeout": {
      "properties": {
        "title": {
          "type": "string"
        },
        "value": {
          "type": "string"
        }
      },
      "type": "object"
    }
  }
}

note: In the current server implementation, Dict in Python doesn't guarantee an order. Which is relevant to the point number 1.

Maybe we can modify the spec to List instead of Dict. In this case, adding a new config value will not need to change in multiple places.

{
  "properties": {
    "configs": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "value": {
            "type": "string",
            "x-nullable": true
          },
          "message": {
            "type": "string"
          }
        }
      }
    }
  }
}

4. Add cluster health values.

What do you think about those suggestions? Suggestions 1-3 are interconnected and can be seen as one issue.