Fixed TRX file overwrite in certain circumstances

[Haplois]

Description

Checks the target file name for saving the TRX logs and insures it is distinct. This check does not occur if a filename is implicitly set, in this case file will be overwritten and a warning is shown.

Related issue

Fixes #2489

[ghost]

Hello @Haplois!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[nohwnd]

I would avoid using pessimistic concurrency, and instead bump the timestamp when we get a conflict. Maybe pass the trx filename as an object / strategy that can easily regenerate it, or if that would change the public APIs just use our knowledge of the format (as you already do) and bump the timestamp and retry.

[nohwnd]

I did have a look, as you requested, and it still seems very complex for what is basically a retry operation, but maybe I am not grasping the details.

I think it might get easier if we passed in an object that contains the raw data that we used to generated the filename and provides a method to get Next, and it also indicates whether or not we should be rewriting because based on whether the user provided the name or not. At least that is how I understand from you this is determined. This would avoid the timestamp parsing code, and it looks like all the appropriate methods are internal so we should not have problem with changing public APIs.

Let's talk about this a bit more during our sync.