metadata: make Stringer implementation consistent

[dims]

Please see the following kubernetes/etcd test scenario failure:
kubernetes/kubernetes#125688

and notes from @serathius here on why this is important for etcd watches to work:
#7137 (comment)

RELEASE NOTES:

• metadata/metadata: ensure the String interface for pretty printing MD is consistent

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.36%. Comparing base (98e5dee) to head (460df21).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7355      +/-   ##
==========================================
- Coverage   81.47%   81.36%   -0.12%     
==========================================
  Files         348      348              
  Lines       26761    26754       -7     
==========================================
- Hits        21804    21768      -36     
- Misses       3772     3787      +15     
- Partials     1185     1199      +14     

Files	Coverage Δ
metadata/metadata.go	89.09% <100.00%> (-0.66%)	⬇️

... and 14 files with indirect coverage changes

[easwars]

Also, the associated unit test needs to be fixed.

[dims]

thanks for the quick review @easwars !

[dims]

Also, the associated unit test needs to be fixed.

@easwars added a couple more variations to the test case

[dims]

@easwars Do i need to do something to trigger the tests? please let me know. ( checked https://github.com/grpc/grpc-go/blob/master/CONTRIBUTING.md before asking :) )

[dfawley]

I agree this is a regression that we should fix, because Go's fmt("%v", <map>) guarantees a consistent output.

But a small nit about terminology: let's use something like "consistent" or "consistently ordered" instead of "deterministic" to not imply that one can depend on the output being something well-defined that will be the same between releases.

[AnomalRoil]

Sorry for that. I didn't mind the inconsistent output, following the logic from golang/protobuf#1121 (comment)

But it's true that printing a <map> in Go is consistent, I should have done that too.

[dims]

But it's true that printing a <map> in Go is consistent, I should have done that too.

No worries at all @AnomalRoil - at least we caught it early enough.

[dims]

@easwars @dfawley all outstanding comments were addressed. thanks!

[dfawley]

Thanks for the PR!

[dims]

thanks for the quick engagement/reviews @easwars @dfawley

[dims]

@easwars @dfawley i have a cherry pick PR open for v1.64.x #7366 .. However i see a v1.65.x branch as well, Should i open one against that too?

[dfawley]

@dims - yes, please! we haven't yet released 1.65.0 but will be doing so very soon.

[dims]

Done! filed #7367 for v1.65.x

[dims]

we haven't yet released 1.65.0 but will be doing so very soon.

@dfawley is there a v1.64.1 as well soon? (pretty please!) will help us update OTEL (plus grpc!) to newer versions in k8s (had to revert that PR)

[dfawley]

is there a v1.64.1 as well soon?

Yes, we will try to get that out next week.