Refactor grofer to make it more extensible ✨

[MadhavJivrajani]

👏 Major 👏 Changes 👏

The main theme of this refactor is to make grofer more extensible and to avoid duplicating and writing redundant boilerplate for every new command created. grofer still has a long way to go in terms of code quality, but this is defintiely a start in the right direction.

Design: The design of grofer now more closely resembles a producer-consumer model of doing things.

MetricScraper - A MetricScraper is any entity that scrapes metrics of any form and Serves them. A MetricScraper also has the ability to set a Sink. Meaning that it can choose what the consumer of the produced metrics will be.

MetricScraperFactory - A MetricScraperFactory produces MetricScrapers based on what the command is. The main purpose of a MetricScraperFactory is to provide a uniform set of functions using which a MetricScraper can be Constructed for any command.

The advantage that the above two abstractions provide is that it allows us to introduce new scrapers independant of the code in the cmd directory and also allows us to introduce new Sinks irrespective of the scrapers present.

As of now, only one sink exists - TUI. Which is the TUI of grofer that consumes the produced metrics. Ideally, export should also be a sink, but this isn't possible with the current state because of non-uniform data formats being used. Once these formats are unified, sinks can be added independent of scrapers and vice-versa.

Directory structure (trimmed, not including non-code files):

├── cmd
├── pkg
│   ├── core
│   ├── export
│   ├── metrics
│   │   ├── container
│   │   ├── factory
│   │   ├── general
│   │   └── process
│   ├── sink
│   │   └── tui
│   │       ├── container
│   │       ├── general
│   │       ├── misc
│   │       └── process
│   └── utils
│       └── visualization
└── scripts

• The previously src directory is now renamed to pkg directory due to convention.
• metrics contains the logic and implementation of different MetricScrapers and the MetricScraperFactory.
• Directories like metrics/container contain scraper specific logic to actually get metrics.
• Files like metrics/factory/container_metrics.go contain the implementaion of MetricScraper for a container metrics specific MetricScraper.
• In each implementation of MetricScraper, the Serve() method is reponsible for choosing between sinks.
• FactoryOptions are used to inject command specific configuration into the MetricScraper implementation.
• sink contains the different sinks that can consume metrics.
• The core package contains different command and sink types, and also some custom errors.
• Each command in the cmd directory uses a seperate command struct to and associated functions to abstract details from top level functions in cobra.

Misc changes:

• Everywhere interfaces and their corresponding implementations are involved:
  • Interface compliance checks are included.
  • This is done to catch any errors at compile time in case interfaces either upstream or downstream change.
• File names of the form fileName.go are changed to file_name.go because camel case in file names is weird.
• The script to check licenses now aggregates all files that don't have licenses and then exits with non-zero code.
  • Previously this used to exit with non-zero code on occurence of the first such file.
  • Ironic isn't it? Considering its in python :p

[MadhavJivrajani]

@Gituser143 made the changes discussed on call, along with refactoring error art ;)