Fix checks processing for multiple connectors

[linkous8]

• Set Initial ready value to false so we don't report ready when no
  checks are run
• Reduce all progressive check event results into single list of checks
  instead of only processing the first result
• refactor non-progressive check readiness accumulation to report
  unready if no checks are run or any connector responds with empty list
  of checks
• fix successful prometheus check reporting caused errors when logged
  due to curly braces in the check names
• fix kubernetes checks shadowed by opsani_dev checks by renaming
  check methods to produce unique check IDs

[linear]

ENG-503 Servox CLI check command does not process all checks

While testing the HPAPlus connector (ENG-466) I ran across an issue where the opsani_dev checks were not showing up in the output as well as all checks being reported as passing which prevented envoy-proxy from being injected into the target application

Example output of this behavior is attached:

• In servo_log1.log you can see only the checks for the HPAPlus connector were reported on
• In servo_log2.log you can see only the checks for the Kubernetes connector were reported on

After digging into the check code, I think I've found the source of the issue here:

servox/servo/cli.py

Line 1331 in 53078f3

if result := next(iter(results), None):

What happens is the logic is only processing check results for the first event result in the list of results without processing any subsequent results in that list which means its only processing the checks for a single connector before considering all checks to have passed. I have a proposed fix which I will push for testing shortly after this ticket is created

servo_log1.log

servo_log2.log

[ekalosak]

LGTM, if I got it right, the changes are:

1. Multiple checks work now
2. Curly brackets no longer kill logger, solved using the escaped_name
3. Naming convention changes in the connectors

Question:

1. Does the if results have the side effects of iter or next on the results generator? Or is the truthyness check blissfully devoid of side effects?
2. Why use functools when you could do sum([b.value for b in results])?

[linkous8]

Corrections:

1. Multiple checks work now

Checks from multiple connectors work now

3. Naming convention changes in the connectors

The check functions have been renamed to avoid duplicate IDs but there is no enforcement of a naming convention WRT to avoiding duplicate IDs yet (Task has been added to the backlog for this)

Answers:

1. Does the if results have the side effects of iter or next on the results generator? Or is the truthyness check blissfully devoid of side effects?

You may need to elaborate more on what you mean by the side effects but I think the answer is that the truthyness check of the results list is devoid of side effects. The next and iter calls being replaced were the logical equivalent of other languages' firstOrDefault methods which was the source of this bug

2. Why use functools when you could do sum([b.value for b in results])?

Mainly for styling reasons. @blakewatters established a precedent for avoiding comprehensions in favor of map/filter/reduce calls which I try to follow (I assume he finds it more readable that way)

[ekalosak]

re Blake using map(reduce(lambda)), I think he's the only one... It goes against most Python style guides iirc. I think, unless he shows up himself to deny, this is a Life of Brian moment.

e.g. Google Python style guide