idea: Non-blocking signal of Nighthawk breakages as part of CI

Background: Nighthawk is (by design) closely coupled to Envoy internals. A company that uses both has to import both at the same time and resolve any build breakages. Nighthawk has its own set of owners that maintain it and submit updates that catch up with Envoy's changes (e.g. https://github.com/envoyproxy/nighthawk/pull/699).

Problem: Envoy developers making code changes are in the dark when making decisions on whether a piece of code is being used / required. While the Envoy developers aren't required to maintain Nighthawk, having some visibility into how a PR affects the Nighthawk's use case may save developer cycles.

Example: See https://github.com/envoyproxy/envoy/pull/16865. If the Envoy dev who worked on the original PR knew about the Nighthawk use case, they could have decided to add the accessor methods. The end result is the same, but two more developers were involved in resolving the issue.

Proposal for discussion: We could add a non-blocking CI workflow that would just build (i.e. not test to ensure lack of flakes) the Nighthawk repo at each Envoy PR. This would achieve two things:

1. The Envoy devs would be making informed decisions.
2. The NH devs would also get an early warning about breakages. To be noted (2) could be achieved by a CI check in Nighthawk's repository, however (1) is considered more valuable here.

Assumptions: We retain the existing split of responsibilities, Envoy devs aren't responsible for and aren't going to fix Nighthawk breakages. This would serve as an optional signal they may take into account when making design decisions.

Tradeoffs:

• Additional CI cost.
• A build breakage indicated at a PR even if non-blocking could cause confusion if not documented properly.

The confusion could be achieved by a well formed error message with the right documentation.

Please let me know what you think.

/cc @alyssawilk @htuch