Get catalog from runner

[arbulu89]

Implement the backend part of the runner connection to get the catalog.
It includes:

• 2 adapters to get the catalog. The MockRunner, so we don't need a real runner to create the catalog, and the real Runner, which interacts with the runner. The implement an adapter, so we can use one or another, and even make the testing easier.
• Configuration of the adapter and the RUNNER_URL flag
• Update the catalog.json to use the new flat list

TODO next:

• Update the frontend to do some error handling and call the new api correctly

[nelsonkopliku]

Nice! I left a couple of comments but @fabriziosestito can help us better 😄

Then a little reasoning.

This guy exposes an endpoint /api/checks/catalog which actually calls /api/catalog on the runner,

Sort of a proxy, but not even, because it does something, namely grouping a flatted catalog received from the Runner, so we could say this is sort of a BFF feature.

runner response

[
  {
    "id": "156F64",
    "name": "1.1.1",
    "group": "Corosync",
    "provider": "azure",
    "description": "...",
    "labels": "generic"
  },
  {
    "id": "156F64",
    "name": "1.1.1",
    "group": "Corosync",
    "provider": "aws",
    "description": "...",
    "labels": "generic"
  },
  ...
]

web response

[
    {
      "groups": [
        {
          "checks": [
            {
                ...
            }
          ],
          "group": "Corosync"
        },
        {
          "checks": [
            {
              ...
            }
          ],
          "group": "Miscellaneous"
        }
      ],
      "provider": "aws"
    },
    {
      "groups": [
        {
          "checks": [
            {
             ...
            }
          ],
          "group": "Corosync"
        },
        {
          "checks": [
            {
              ...
            }
          ],
          "group": "Miscellaneous"
        }
      ],
      "provider": "azure"
    }
  ]

This is perfectly fine.

Yet I'd consider the opportunity to actually just have a proxy for the time being (an ingress or a proxy controller on web).

Why did we chose to do it this way? Mainly to make the grouping on elixir side I believe.

I believe it can go this way.

[arbulu89]

@fabriziosestito @nelsonkopliku ,
Most of your comments (or all of them) addressed in the last commit: a5d179f

Besides that, I have updated slightly the catalog controller to allow a flat param (api/checks/catalog?flat) which will return the flat version of the catalog.

[arbulu89]

Why did we chose to do it this way? Mainly to make the grouping on elixir side I believe.

I believe it can go this way.

Yes, mostly the idea is to keep the runner as dump as possible, mostly, because doing list operations in golang is more costly (and much more in ansible...).
Finally, using a simple ingress wouldn't be that easy, because the runner has some certain intelligence, like some state where the catalog is not ready yet. Finally, I took the chance of doing some error handling and messages customization. In any case, the catalog controller is really simple at this point, so I hope it doesn't require too much maintenance.

[fabriziosestito]

@arbulu89 left some commends about styles / error handling in general.
Some doubts about the naming of the DTOs / models but we can iterate on it

[arbulu89]

@fabriziosestito yet another round of changes hehe
I have removed the "stringtified" error handling and enforced the usage of FlatCatalog from the adapter