Trying to reason about why it got really tricky to deal with a tempfile to later add as an artifact here:
[1]: https://chromium-review.googlesource.com/c/catapult/+/772831/29..34/telemetry/telemetry/internal/story_runner.py

I noticed there is actually a bug on AddArtifact as currently implemented.

Say we create a tempfile: /tmp/test_ZNsuLC.log
And then we do results.AddArtifact(
   'test1', 'logs', '/tmp/test_ZNsuLC.log')
Which will move 'test_ZNsuLC.log' to the artifacts_dir and register it as a log of test1.

Many tests later, since that name no longer exists on the tempdir, by pure chance the name might be reused.

So we are unlucky and create again: /tmp/test_ZNsuLC.log
And then we do results.AddArtifact(
   'test42', 'logs', '/tmp/test_ZNsuLC.log')
Which will move 'test_ZNsuLC.log' to the artifacts_dir, overwriting the logs from test1.

Now even more I think having the ArtifactResults object moving files into the artifacts_dir is problematic (because we'll always be liable to this sort of collisions) and we should try to avoid that as much as possible. Instead we should try to create the files _within_ the artifacts_dir to begin with.

For this particular case, my proposal would be to have some, say, CreateArtifact method that would:

- automatically create a new file name _within_ the artifacts_dir (e.g. using the `dir` option of tempfile.mkstemp or tempfile.NamedTemporaryFile)
- ensure the file is added to the artifacts list *even in the case of failure* since particularly in case of failure is when we want to ensure that logs are preserved.

Then, rather than the current tmpfile dance in [1], we could simply do:

    with results.CreateArtifact('test42', 'logs') as log_file:
      with logging_util.CaptureLogs(log_file):
        logging.info('Add this to the logs')