Thanks! The tools I used to run coverage reports don't lend themselves well to doing coverage diffs (manual sponge executions). I'll take another pass at it using some different tools and see if I can get a better delta.

I pieced together a system to merge and diff lcov files in a reasonable amount of time without crashing our build servers, 13,000 lcov files > 12GB file upload limit. Sponge coverage does not support one-off diffs. It'll take some more work to get coverage set up systematically so we can see this at a glance, but I see some paths to get there, and we should get there eventually.

This exercise compares individual runs of end2end:all and therefore it may not be perfectly accurate (some test runs may exercise different retry paths, spurious error paths, etc). It's about an hour of manual work to generate these results, so I think this will have to suffice for now. More broadly, end2end tests only cover ~45% of src, so we should monitor and improve coverage generally anyhow.

What I found is, I think, mostly coverage that may differ between individual test runs. Of the ~85,000 instrumented lines:

45 lines are exercised in the baseline but not covered here

Examples:

• src/core/lib/transport/metadata_batch.h.gcov.html: a no-op method EncodeTo is called in the baseline, but not in this PR
• src/core/lib/surface/completion_queue.cc.gcov.html: CheckReadyToFinish is evidently exercised in the baseline, but not in a single run of end2end tests via this PR.

76 lines are exercised in this pr, but not in the baseline

Examples:

• src/core/ext/transport/chttp2/transport/chttp2_transport.cc: no unseen streams to cancel
• src/core/lib/iomgr/ev_poll_posix.cc: whether notification is requested after shutdown,
• src/core/lib/iomgr/tcp_posix.cc: code to handle a recvmsg failure

I have 1MB lcov diff files I can share for both scenarios. But I didn't see anything critical

@drfloob I'd be curious to know the impact on the total test runtime for the entire C core test suite (e.g. when you run all the tests locally). I suspect there'll be a noticeable improvement in the total test runtime (since you're removing a lot of tests). I also expect a significant reduction in the number of test targets).

@drfloob also, can you confirm that this PR will solve #27733?

@jtattermusch Yes, this fixes #27733, and unblocks #28667 for the same reasons. The end2end total test count goes down from about 11k to 7k, which cuts a few minutes off of the total runtime for internal test jobs (600 running in parallel). Do you want to take any other baseline measurements before I land this?

@jtattermusch Actually I realize you just finished collecting a large swath of metrics, so I think we should be good to go for this PR.