Currently, JMeter notifies TestStateListener from a single thread only, and it collects listeners **before** they are cloned for the execution.

For instance, HTTPSamplerBase is cloned for every thread (because it has execution state fields), so it looks strange to implement TestStateListener. What was the expected outcome? Did HTTPSamplerBase authors expect that JMeter would execute "testEnded" on each cloned HTTPSamplerBase instance? Did HTTPSamplerBase authors expect that "testEnded" would be called for "non-cloned" instance only? Frankly speaking, both options sound strange to me, and I think HTTPSamplerBase should not really implement TestStateListener.

That creates two issues:
1) StandardJMeterEngine keeps the collection (see SearchByClass<>(TestStateListener.class)) of all TestStateListener implementations for the duration of the test.

2) HTTPSamplerBase is cloned into the execution threads, so it is unclear what would be outcome of calling the notifications (testStarted, testEnded) on an element that is not associated with a thread.

I'm inclined we should deprecate TestStateListener for objects cloned into individual execution threads. In other words, it looks like TestStateListeners should be executed for "global-like" services only.

Of course, we could try calling "testStarted" within each execution thread, however, I am not sure what would be the use case for it, and it was not implemented previously.