Ownership integration

[unflxw]

Implements an integration for the ownership gem, as discussed on Slack.

Commits

Add instrument_ownership config option

Add a new instrument_ownership configuration option that can be
used to toggle off instrumentation for the ownership gem.

Add after_create transaction hook

Add a hook that allows for blocks of arbitrary code to be applied to
modify a transaction after it has been created.

Add before_complete transaction hook

Add a before_complete transaction hook, which is executed right
before a transaction is completed. Note that, for transactions
containing multiple errors, this hook is called once for each of
the duplicate transactions that is used to report each of the
errors. This allows the context to be customised for each error.

Instrument ownership gem

Add an instrumentation for the ownership gem. When a transaction
is created, if an owner has been set in the gem, use the name of
the owner as the namespace for the transaction. Do the same when an
owner is set during an active transaction.

If more than one owner is set during a transaction, the namespace
will be that of the last owner that was set.

Notes

@thijsc mentioned it would be nice to contribute this to the gem itself. I took a look at that, but I noticed we'd need something like the after_create and before_complete hooks in this PR to make it work. That said, now that those hooks exist, it should be possible to make them part of the public API, discard the instrumentation in this PR, and instead contribute an instrumentation as a PR to the gem.

@matsimitsu suggested using the owner information to automatically assign errors (and performance issues?) to teams, instead of setting the owner as the namespace. At the moment, this PR uses namespaces, but we could use team assignments instead, or alongside it. Beyond this gem, customers might find it useful to be able to set metadata on their transactions and traces that causes them to automatically be assigned to a team or person. I'm unsure how much work that would be, though.

Regarding testing it, I attempted to use a mock to test it, like we do for several other dependencies. It is possible, but I found myself re-implementing the gem and doubting whether my implementation was an accurate representation of the original, so I decided to add a gemfile instead. I'm happy to reconsider this if we want to avoid the additional gemfile and its corresponding CI runs.

[backlog-helper]

✔️ All good!

New issue guide | Backlog management | Rules | Feedback

[unflxw]

@tombruijn I'm interested in any thoughts about the transaction after_create and before_complete hooks, especially if it seems like a bad idea to add these.