deps: update golang.org/x/net to v0.47.0 (tagged version)

[thaJeztah]

• follow-up to transport: Avoid buffer copies when reading Data frames #8657

commit 363018c updated the golang.org/x/net dependency to unclude some changes that had not yet been released. Now that v0.47.0 was released, we can switch back to released versions.

full diff: golang/net@63d1a51...v0.47.0

RELEASE NOTES: N/A

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.28%. Comparing base (749af0c) to head (ce83f19).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8732      +/-   ##
==========================================
- Coverage   83.30%   83.28%   -0.03%     
==========================================
  Files         419      419              
  Lines       32450    32450              
==========================================
- Hits        27033    27025       -8     
- Misses       4039     4046       +7     
- Partials     1378     1379       +1     

see 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[thaJeztah]

/cc @dfawley @easwars

[arjan-bal]

LGTM. We usually bump all dependencies every 6 weeks after cutting release branches. @thaJeztah, were you facing any issues with the version of x/net used by gRPC?

[arjan-bal]

Adding a second reviewer.

[thaJeztah]

were you facing any issues with the version of x/net used by gRPC?

No immediate issue; I noticed that un-tagged versions started to show up in various projects I maintain, so I started looking where they originated from (usually they come from smaller projects where someone accidentally did an update to master / main of a dependency).

Where possible, we try to stick to released versions mostly for hygiene, but also because Go's pseudo-versions don't work well with dependencies that use release branches (in which case a version may actualy be "higher" than a tagged release, and there's a risk of go modules downgrading them).

We usually bump all dependencies every 6 weeks after cutting release branches

Yes, that makes sense; even for those, it may be good to only update if there's a need; go modules are designed around MVS (Minimum Version Selection) and for library modules it's good to keep versions low if there's no need to update; this can help project that maintain release branches of their own. Often we run into situations where a bugfix that's relevant (but only available in the latest version) also forces us to take a gazillion other dependency updates, which now makes it much more risky to do. Keeping required versions low allows projects to decide whether they want to update other dependencies (where needed), instead of being forced to.