sdk/metric: fix data race in NewPeriodicReader

[ShreeyashPatil2708]

Fixes #8769

NewPeriodicReader started the background goroutine before initializing r.inst, creating a data race between the constructor's write and the goroutine's read of that field via collect(). This moves the r.inst initialization before the goroutine launch to eliminate the race.

Added TestNewPeriodicReaderConcurrentSafe which reproduces the race under -race and passes after the fix.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ShreeyashPatil2708 / name: ShreeyashPatil2708 (6930cec)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.4%. Comparing base (58db4c8) to head (4a1ca17).
⚠️ Report is 32 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #8842   +/-   ##
=====================================
  Coverage   88.4%   88.4%           
=====================================
  Files        331     331           
  Lines      21001   21001           
=====================================
+ Hits       18571   18574    +3     
+ Misses      2430    2427    -3     

Files with missing lines	Coverage Δ
sdk/metric/periodic_reader.go	87.1% <100.0%> (ø)

... and 16 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[pellared]

panic: test timed out after 1m0s
	running tests:
		TestNewPeriodicReaderConcurrentSafe (59s)

[MrAlias]

The constructor ordering fix looks correct. The new regression test needs to isolate its expected error handling so the compatibility suite does not deadlock.

[MrAlias]

This test intentionally allows collection before register to exercise the constructor race, which also sends ErrReaderNotRegistered through the process-global error handler. Existing tests can leave a handler that blocks or refers to an already-completed test; CI hit the blocking path and left Shutdown waiting on r.done.

Could we install a known non-blocking error handler for this test and restore the previous handler in cleanup?

[ShreeyashPatil2708]

done, pls check

[MrAlias]

The constructor reordering itself fixes the reported unsynchronized access, and the no-op error handler resolves the previously reported test deadlock. The sdk/metric package passes locally under the race detector. GitHub CI remains mostly pending after the latest merge from main.

[MrAlias]

The test does not reliably exercise the pre-fix race. After restoring the old constructor ordering, it still passed under go test -race for 100 repetitions—5,000 reader constructions—because nothing ensures the run goroutine reads r.inst before NewInstrumentation assigns it.

Could we synchronize the test around that window so the old ordering fails deterministically? Otherwise the regression can return while this test remains green.

[ShreeyashPatil2708]

will work on it, give me a couple of days...