feat: add error.transaction.name

[trentm]

Add transaction.name to errors captured in the context of a
transaction. This allows APM UI to have fields used for transaction
grouping, which allows correlating error groups to transaction groups.

Closes: #2456

Checklist

• Implement code
• Add tests
• Add CHANGELOG.asciidoc entry (I'm waiting for feat: align on 'unknown-{service.agent.name}-service' default service_name #2538 to get merged first to avoid a merge conflict.)
• Sanity check that we don't need to only add error.transaction.name for recent APM Server versions. This was added in APM Server 8.0.

[trentm]

• Sanity check that we don't need to only add error.transaction.name for recent APM Server versions. This was added in APM Server 8.0.

Correct. We do not. Per https://json-schema.org/understanding-json-schema/reference/object.html#additional-properties "By default any additional properties are allowed."

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-01-24T15:54:57.412+0000

• Duration: 20 min 27 sec

• Commit: 3ac23f0

Test stats 🧪

Test	Results
Failed	0
Passed	243005
Skipped	0
Total	243005

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run module tests for <modules> : Run TAV tests for one or more modules, where <modules> can be either a comma separated list of modules (e.g. memcached,redis) or the string literal ALL to test all modules

• run benchmark tests : Run the benchmark test only.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[trentm]

Spurious failure in GH Action "Test / test-vers (17)" test run:

# system.memory.actual.free
ok 74 is present
ok 75 is a number
ok 76 is finite (was: 2799632384)
not ok 77 is larger than os.freemem() (value: 2799632384, free: 2799632384)
  ---
    operator: ok
    expected: true
    actual:   false
    at: Object.system.memory.actual.free (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/test/metrics/index.test.js:83:13)
    stack: |-
      Error: is larger than os.freemem() (value: 2799632384,
                free: 2799632384)
          at Test.assert [as _assert] (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/node_modules/tape/lib/test.js:314:54)
          at Test.bound [as _assert] (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/node_modules/tape/lib/test.js:99:32)
          at Test.assert (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/node_modules/tape/lib/test.js:433:10)
          at Test.bound [as ok] (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/node_modules/tape/lib/test.js:99:32)
          at Object.system.memory.actual.free (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/test/metrics/index.test.js:83:13)
          at Object.sendMetricSet (/home/runner/work/apm-agent-nodejs/apm-agent-nodejs/test/metrics/index.test.js:142:20)
          at /home/runner/work/apm-agent-nodejs/apm-agent-nodejs/lib/metrics/reporter.js:57:34
          at /home/runner/work/apm-agent-nodejs/apm-agent-nodejs/node_modules/after-all-results/index.js:20:25
          at processTicksAndRejections (node:internal/process/task_queues:78:11)
  ...

I wonder if /proc/mem's "MemFree" can be the same (or close, given we are sampling at different times) to the "MemAvailable" -- though it is typically smaller. If so, then this is a flaky test and the test condition should be changed.

Update: ^^ handled in #2540

[astorm]

👍 Does the thing, no obvious negative consequences. Approving.