[chore] Force require.EventuallyWithT to fail properly

[djaglowski]

I noticed on #34720 and #35026 that execution of the test continued beyond a failure of require.EventuallyWithT. Based on the description alone, I would expect that using assert within require.EventuallyWithT should cause execution to stop if the assertion fails, but it appears this may not be the case. However, this change apparently works as intended.

[djaglowski]

I'm not sure this should be merged until we have a more wholistic understanding of the failures mentioned here.

[pjanotti]

I agree @djaglowski - Unfortunately, after that initial series of failures that I mentioned in the comment that you linked, the failures went away without any clear action on my part. Reviewing the code I detected a small thing that should be changed as precaution: if the first run of the tests fails without running the deferred code, the second run will fail on the registry entry already being present so no second run. I'm not convinced that it is a real problem in practice, but, let me clear that in quick PR and afterwards I will monitor the failures to see if we can get a better grip on what is going on with these tests.

[pjanotti]

Created #35168 to handle the comment above.

[djaglowski]

This change still appears to surface a failure:

=== FAIL: . TestReadWindowsEventLogger (unknown)
panic: Assertion failed

goroutine 21 [running]:
github.com/stretchr/testify/assert.(*CollectT).FailNow(0x1417376c0?)
	C:/Users/runneradmin/go/pkg/mod/github.com/stretchr/testify@v1.9.0/assert/assertions.go:1924 +0x2b
github.com/stretchr/testify/require.Len({0x14173b120, 0xc0001121f8}, {0x14136fd80, 0x141f8d6a0}, 0x1, {0x0, 0x0, 0x0})
	C:/Users/runneradmin/go/pkg/mod/github.com/stretchr/testify@v1.9.0/require/require.go:1159 +0xf1
github.com/open-telemetry/opentelemetry-collector-contrib/receiver/windowseventlogreceiver.requireExpectedLogRecords.func1(0xc0001121f8)
	D:/a/opentelemetry-collector-contrib/opentelemetry-collector-contrib/receiver/windowseventlogreceiver/receiver_windows_test.go:330 +0x131
github.com/stretchr/testify/assert.EventuallyWithT.func1()
	C:/Users/runneradmin/go/pkg/mod/github.com/stretchr/testify@v1.9.0/assert/assertions.go:1983 +0xb8
created by github.com/stretchr/testify/assert.EventuallyWithT in goroutine 15
	C:/Users/runneradmin/go/pkg/mod/github.com/stretchr/testify@v1.9.0/assert/assertions.go:1978 +0x42b

I think this is legitimate because #35026 fails as well, but in a less clear way because the actual failure is ignored.

[pjanotti]

@djaglowski let's merge this one and observe on the CI runs. One thing that I also want to do is to remove the single t.Parallel() because it makes the test using it to show in the failure that you linked, but, I think that it is just a red-herring. I will create a PR for that shortly.

[pjanotti]

To remove t.Parallel() #35178