Bump grpcio from 1.19.0 to 1.53.0 in /src/stirling/testing/demo_apps/py_grpc

[dependabot]

Bumps grpcio from 1.19.0 to 1.53.0.

Release notes

Sourced from grpcio's releases.

Release v1.53.0

This is release 1.53.0 (glockenspiel) of gRPC Core.

For gRPC documentation, see grpc.io. For previous releases, see Releases.

This release contains refinements, improvements, and bug fixes, with highlights listed below.

Core

• xDS: fix crash when removing the last endpoint from the last locality in weighted_target. (#32592)
• filter stack: pass peer name up via recv_initial_metadata batch. (#31933)
• [EventEngine] Add advice against blocking work in callbacks. (#32397)
• [http2] Dont drop connections on metadata limit exceeded. (#32309)
• xDS: reject aggregate cluster with empty cluster list. (#32238)
• Fix Python epoll1 Fork Support. (#32196)
• server: introduce ServerMetricRecorder API and move per-call reporting from a C++ interceptor to a C-core filter. (#32106)
• [EventEngine] Add invalid handle types to the public API. (#32202)
• [EventEngine] Refactoring the EventEngine Test Suite: Part 1. (#32127)
• xDS: fix WeightedClusters total weight handling. (#32134)

C++

• Update minimum MSVC version to 2019. (#32615)
• Use CMake variables for paths in pkg-config files. (#31671)

C#

• Grpc.Tools: Use x86 protoc binaries on arm64 Windows. (#32017)

Python

• Support python 3.11 on aarch64. (#32270)
• Include .pyi file. (#32268)
• De-experimentalize wait-for-ready. (#32143)
• De-experimentalize compression. (#32138)

Ruby

• [ruby]: add pre-compiled binaries for ruby 3.2; drop them for ruby 2.6. (#32089)

Release v1.53.0-pre2

This is a prerelease of gRPC Core 1.53.0 (glockenspiel).

For gRPC documentation, see grpc.io. For previous releases, see Releases.

... (truncated)

Changelog

Sourced from grpcio's changelog.

gRPC Release Schedule

Below is the release schedule for gRPC Java, Go and Core and its dependent languages C++, C#, Objective-C, PHP, Python and Ruby.

Releases are scheduled every six weeks on Tuesdays on a best effort basis. In some unavoidable situations a release may be delayed or released early or a language may skip a release altogether and do the next release to catch up with other languages. See the past releases in the links above. A six-week cycle gives us a good balance between delivering new features/fixes quickly and keeping the release overhead low.

The gRPC release support policy can be found here.

Releases are cut from release branches. For Core and Java repos, the release branch is cut two weeks before the scheduled release date. For Go, the branch is cut just before the release. An RC (release candidate) is published for Core and its dependent languages just after the branch cut. This RC is later promoted to release version if no further changes are made to the release branch. We do our best to keep head of master branch stable at all times regardless of release schedule. Daily build packages from master branch for C#, PHP, Python, Ruby and Protoc plugins are published on packages.grpc.io. If you depend on gRPC in production we recommend to set up your CI system to test the RCs and, if possible, the daily builds.

Names of gRPC releases are here.

Release	Scheduled Branch Cut	Scheduled Release Date
v1.17.0	Nov 19, 2018	Dec 4, 2018
v1.18.0	Jan 2, 2019	Jan 15, 2019

Commits

• 358bfb5 Bump version to 1.53.0 (#32685)
• 6e1ebe7 Backport: Ensure compatibility with the new custom kokoro win2019 image (#326...
• 44a77f6 Backport 1.53: Update minimum MSVC version to 2019 (#32615)
• c11153c backport to 1.53: xDS: fix crash when removing the last endpoint from the las...
• 7c7712a Bump version to 1.53.0-pre2. (#32545)
• a4017dc backport to 1.53: [promises] Make Poll<T> its own type, not a variant<> (#32540)
• 3f93c16 Fuzzer fix backport to v1.53 (#32511)
• 5b244b2 Bump release version to 1.53.0-pre1 (#32428)
• 6589340 Bump core version 202302161703 (#32416)
• d49e151 [backoff] Add random early detection classifier (#32354)
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[ddelnano]

This will break our grpc_trace_bpf_test. The newest grpc c version we support is 1.33.2. We will need to spend time determining the offsets for newer versions before a version this new can be used.

[ddelnano]

@vihangm not sure if you saw my earlier comment, but we can't merge this until we determine the offsets for this grpc c version. I'm going to investigate what those offsets are for this upgrade.

[ddelnano]

From talking with the Groundcover folks, this isn't as simple as adding offsets for the new grpc-c library version. Part of the API changed and the tracing needs to be adapted to reflect that.

Therefore this will be quite a bit of work and not something the Stirling team will be able to take on soon. Since the tracing needs more substantial changes, I think it's worth considering if the current approach is the right one. Our recent BoringSSL work resulted in a more maintainable tracing solution and maybe those learnings or another solution could be applied here.

[dependabot]

Superseded by #1977.