coverage takes excessive time while recording tests

[dgkf]

The bitops package's coverage execution duration is increased by multiple orders of magnitude while running with covr.record_tests = TRUE

[dgkf]

Taking some notes:

1. Testing system times after cutting down the number of replicates:

   for (N in ..)	Time (s)	Coverage (lobstr::obj_size())
   1:1	~2	2MB
   1:5	~2	4MB
   1:50	10	26MB
   1:500	700	250MB

2. covr is recording a test call stack for every call (n=28) to bitops functions within the tight loop (N=5000 repetitions)
   1. This is unsurprising because we currently only check to see if the test call stack is identical, and if not we record a new test.
      covr/R/trace_tests.R#L101-103

        if (is_current_test_finished()) {
          update_current_test()
        }

   2. Alternatively, we could be more mindful about which tests are identical to the current test down to which part of the call stack. If we wanted to re-use the same recorded test call stack we would walk our way back up through the relevant subsets of the recorded test calls.
      I'd want to profile covr before we go too far down this path to figure out what needs to be optimized.

[dgkf-roche]

Idea from @maksymiuks, store a hashmap so that we can more easily check to see if test has already been executed

[dgkf]

@maksymiuks - quickly tried out your approach and it drops execution time and object size down by an order of ~20x. Turns out we already had a style of hashing, but only in cases where the source refs were available, and when they're not we'd do a really costly comparison and resort to pushing new test traces into the log.

In my little naive test I just fell back to a digest hash instead of no hash at all.

for (N in ..)	Time (s)	Coverage (lobstr::obj_size())
1:500	30	1MB
1:5000	280	3.36MB

I'll put together a proper patch tomorrow and make sure I'm not accidentally breaking something in the process.

[dgkf]

Digging a bit deeper, I think there are two problems here.

1. The first is related to the changes for scrubbing function environments, which simultaneously removes srcref information making it impossible to derive a source ref.
2. This causes the current covr to fall back to using an empty name, which means that every new trace goes through a very slow comparison against all previous tests.

The first problem is accidentally and has introduce a pretty steep performance cost. Reverting that is pretty trivial - just moving the environment cleanup until after we have a name for the test derived from the source ref.

The second problem is that bitops testing doesn't capture srcref, so it gets hit doubly by this problem and uses the slowest possible path to find recurring tests. Falling back to a digest of the call stack allows for a faster lookup.

This also uncovered an existing issue in covtracer that emits a warning when a test doesn't have a srcref. We almost never encounter this because we already run against packages installed with srcref info.