chore(ci_visibility): add support for bitmap-based coverage data

[romainkomorndatadog]

Per a new RFC, line-level coverage data is changing from using the current segment tuples to msgpack-encoded bytes (with little-endian ordering).

CoverageLines

CoverageLines are introduced representation of coverage in the ModuleCodeCollector, providing a minimal, set-like API, and using a bytes-based internal storage (with bit-shifty fun to account for the desired little-endianness). A from_list() classmethod is added for convenience in test updates.

Encoder changes

The new coverage format is stored using Span.set_struct_tag() with a dictionary similar to the existing segments-based one:

{
  "files": [
    {
      "filename": "/src/flask/helpers.py",
      "bitmap": bytearray(b"..."),
    }
  ]
}

Paths are relative to the repo or workspace root, but prepended with a / to make them absolute (this is something that is already done by the backend, but doing it on the client means the backend is not modifying the tracer's payloads).

The encoder is temporarily updated to look for the COVERAGE_TAG_NAME in both the regular tags and struct tags.

ModuleCodeCollector changes

The communication between threads and processes patched for coverage support is switched from JSON to pickling (so that bytes don't need to be converted to an array and then back to bytes). The pickling statements have the nosec comment because we know the source of the data.

Tests

Tests are updated to account for differences in plugin versions, and some utility methods are added to parse the two different coverage data formats into an intermediary format that can be checked for both without too much conditional hassle.

No release note is added because the internal code coverage collector and the v2 plugin are still unreleased, and the other changes are backwards-compatible.

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy