Add stringSlice and int64Slice to pcommon, and let tests handle non-number slices

[dmathieu]

Description

This adds a string slice to pcommon, that will be used by the profiles pdata.

Link to tracking issue

Part of #10109.

Testing

This is unit-tested.

cc @mx-psi

[codecov]

Codecov Report

Attention: Patch coverage is 79.33884% with 25 lines in your changes are missing coverage. Please review.

Project coverage is 92.15%. Comparing base (e7dcfcc) to head (83f82f1).

Files	Patch %	Lines
pdata/internal/generated_wrapper_byteslice.go	0.00%	5 Missing ⚠️
pdata/internal/generated_wrapper_float64slice.go	0.00%	5 Missing ⚠️
pdata/internal/generated_wrapper_int64slice.go	54.54%	5 Missing ⚠️
pdata/internal/generated_wrapper_stringslice.go	54.54%	5 Missing ⚠️
pdata/internal/generated_wrapper_uint64slice.go	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10148      +/-   ##
==========================================
- Coverage   92.24%   92.15%   -0.10%     
==========================================
  Files         353      357       +4     
  Lines       16797    16918     +121     
==========================================
+ Hits        15495    15591      +96     
- Misses        963      988      +25     
  Partials      339      339              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mx-psi]

I think this should not be a controversial addition, but since this is adding new API on a 1.0 module I would like other @open-telemetry/collector-approvers to take a look.

AIUI the motivation is to support fields like https://github.com/open-telemetry/opentelemetry-proto/blob/a05597bff803d3d9405fcdd1e1fb1f42bed4eb7a/opentelemetry/proto/profiles/v1experimental/pprofextended.proto#L97, so the risk is that we may not use this after all (sounds very unlikely though)

[bogdandrutu]

I don't see a problem adding these, but want to make sure there is no other way for us to support this (if you have any idea, it would be good to brainstorm here).

[mx-psi]

@dmathieu To confirm: the intent is to use these types for fields like string_table or location_indices, right?

[dmathieu]

Yes, it is. My pdata PR shows that use as well.

[mx-psi]

Thanks for confirming. I will wait until Friday before merging this to give time to others to review

[TylerHelmuth]

Looking at #10109 I only see the new types being used in pprofile. Is it required that the new types be in pcommon?

[mx-psi]

Looking at #10109 I only see the new types being used in pprofile. Is it required that the new types be in pcommon?

IMO it is required after profiling is declared stable. It's not strictly required now, but it's better in that we don't need people to update their import paths for this after profiling goes to 1.0

[TylerHelmuth]

It's not strictly required now, but it's better in that we don't need people to update their import paths for this after profiling goes to 1.0

I guess the risk is that this goes into 1.x pcommon and then needs removed/modified. Unlikely, but how would we handle that? Deprecate it and remove in 2.0?

[mx-psi]

Deprecate it and remove in 2.0?

Yup, it would become dead code

[TylerHelmuth]

What would we do if it needs to be modified instead of removed?

[mx-psi]

What would we do if it needs to be modified instead of removed?

We would have to deprecate it and come up with a different name. I don't think that's going to happen here though, what a StringSlice type should look like is kind of already defined by the other <Type here>Slice types we already support

[mx-psi]

Waiting for v0.101.0 to be released, will merge after that