[pdata] Introduce runtime safeguards to catch incorrect pdata mutations

[dmitryax]

This change introduces an option to enable runtime assertions to catch unintentional pdata mutations in components that are claimed as non-mutating pdata. Without these assertions, runtime errors may still occur, but thrown by unrelated components, making it very difficult to troubleshoot.

For now, this doesn't change the default behavior. It just introduces a new method on [Metrics/Traces|Logs].Shared() that returns pdata marked as shared. The method will be applied to fan-out consumers in the next PR.

Later, if we want to remove the need of MutatesData capability, we can introduce another method [Metrics/Traces|Logs].Exclusive() which returns a copy of the pdata if it's shared.

This change unblocks the 1.0 release by implementing the original solution proposed by @bogdandrutu in #6794. Going forward, we may introduce a copy-on-write solution that doesn't require the runtime assertions. That will likely be part of the 2.0 release.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Files	Coverage Δ
pdata/internal/generated_wrapper_byteslice.go	100.00% <100.00%> (ø)
pdata/internal/generated_wrapper_float64slice.go	100.00% <100.00%> (ø)
...internal/generated_wrapper_instrumentationscope.go	100.00% <100.00%> (ø)
pdata/internal/generated_wrapper_resource.go	100.00% <100.00%> (ø)
pdata/internal/generated_wrapper_uint64slice.go	100.00% <100.00%> (ø)
pdata/internal/state.go	100.00% <100.00%> (ø)
pdata/internal/wrapper_logs.go	100.00% <100.00%> (ø)
pdata/internal/wrapper_map.go	100.00% <100.00%> (ø)
pdata/internal/wrapper_metrics.go	100.00% <100.00%> (ø)
pdata/internal/wrapper_slice.go	100.00% <100.00%> (ø)
... and 68 more

📢 Thoughts on this report? Let us know!.

[codeboten]

Thanks for taking this on @dmitryax, have you run benchmarks to compare the results of this change?

[dmitryax]

@codeboten the performance should not be affected because the additional field is a part of a struct that stays on the memory stack. I added some benchmarks from my previous work to confirm it:

Before:

BenchmarkTracesUsage-10    	    1832	    613221 ns/op	   50631 B/op	    3409 allocs/op
BenchmarkMetricsUsage-10    	     506	   2247812 ns/op	  115778 B/op	    8946 allocs/op
BenchmarkLogsUsage-10    	    5146	    224939 ns/op	   26323 B/op	    1645 allocs/op

After:

BenchmarkTracesUsage-10    	    1795	    615730 ns/op	   50629 B/op	    3409 allocs/op
BenchmarkMetricsUsage-10    	     512	   2288719 ns/op	  115777 B/op	    8946 allocs/op
BenchmarkLogsUsage-10    	    5469	    217728 ns/op	   26321 B/op	    1645 allocs/op

[dmitryax]

Updated PR to add coverage for panics. Had to make some related chores in pdatagen that I moved to another PR #8537