RFE: Automatically analyze gathered bootstrap logs?

When bootstrapping fails but we got far enough in to be able to SSH into the bootstrap machine, the installer automatically gathers a log tarball. But the tarball is probably fairly intimidating to users who aren't on the install team or in the position to be frequently debuggers. And in some cases, the results are sufficiently structured that we can point out a specific problem (e.g. CRI-O failed, #2567) or "you had insufficient creds to pull the release image" (#901). Do we want to teach the installer how to find and highlight some of those cases? We have a fair number of them in the last 24 hours of CI:

$ curl -s 'https://ci-search-ci-search-next.svc.ci.openshift.org/search?name=-e2e-&maxAge=24h&context=0&search=Bootstrap+gather+logs+captured' | jq -r '. | keys[]' | sed 's|.*-e2e-\([^/]*\)/[0-9]*$|\1|' | sort | uniq -c | sort -n
      1 aws-console-olm
      1 azure-master
      1 azure-upgrade-4.2
      1 gcp-console
      1 gcp-upgrade
      1 libvirt
      1 openstack
      1 vsphere
      1 vsphere-upi-serial-4.2
      2 aws-encryption
      2 aws-ovn-kubernetes
      2 aws-ovs-kubernetes-4.3
      2 aws-upgrade
      2 aws-upi-4.3
      2 azure
      2 cmd
      2 tools
      2 wmcb
      2 wsu
      3 gcp
      3 gcp-op
      4 aws-proxy-4.2
      4 aws-proxy-4.3
      4 aws-scaleup-rhel7
      8 aws
     12 vsphere-upi-4.3
     12 vsphere-upi-serial-4.3
     20 aws-4.3

But currently no way to break those down by underlying cause.

Start by reviewing the bootstrap log tarball gathered after a failed bootstrap and the example causes referenced in #2567 and #901. Done should mean the installer can identify and highlight specific underlying failures instead of presenting only an undifferentiated tarball.