running tests under codecoverage is blocked by this, with this change, codecoverage run completed

Actually, if RenderHelper is a hot-spot, read-write lock would be better here.

Also the comment at the top of the file suggests that class code could be simplified, but it's out of scope of this PR

/// This class uses lots of nearly identical helper functions to recursively traverse the tree. If I weren't so pressed 
/// for time, I would see if generic methods could be used to collapse the number of traversers.    

@vors made change to ReaderWriterLockSlim, verifying change

By reading the code, it looks to me that RenderHelper will only be called through ProgressPane.Show, and ProgressPane.Show will never be called from 2 different threads simultaneously -- it's either being called on the pipeline thread, or called from a timer thread, and only one timer thread will be running at any given time. That means at any given time, only 1 thread will be executing RenderHelper method, so a read-write lock won't help improve concurrency.

Second, this lock protects accessing to the type field _topLevelNodes, but there are other type members also shared between the main pipeline thread and _progPane.Show running on the timer thread, _rawui and _progressRegion are another 2 examples. I didn't do thorough analysis to know if those shared members can actually cause other race conditions, but it's possible.

Maybe we should just have a lock in ConsoleHostUserInterfaceProgress.cs to protect the call to _pendingProgress.Update(sourceId, record) in HandleIncomingProgressRecord and the call to _progPane.Show(_pendingProgress) in ProgressPaneUpdateTimerElapsed. I think that will cause very minimum performance degradation to the timer improvement.

@lzybkr @iSazonov Any thoughts?

If we are manipulating data structures as part of showing progress, maybe a timer was the wrong approach - it seems possible that we might make a mess of things somehow by not rendering everything that was asked of us.

On the other hand, maybe the progress rendering handles such cases already on the assumption that the user did a poor job, e.g. not reporting the completion of some child event.

It turns out the current timer approach could result in more potential race conditions, for example, the timer might be disposed on the main pipeline thread while it's being called on the timer thread, the _progPane.Hide() might be called in ResetProgress on the main pipeline thread, while _progPane.Show is running on the timer thread. After talking to @SteveL-MSFT and @lzybkr, we feel the safest fix for now (to unblock CI/daily build) is to revert the original timer change. I will re-open the original Write-Progress issue too. /cc @iSazonov

I will close this PR and submit another one to revert the timer change.

The new PR is #2806.