feat(logs): add ability to capture and send logs

[lcian]

• Adds the ability to capture Logs with a method capture_log on the Hub that takes in a Log.
• The features are gated behind an UNSTABLE_logs flag. This is needed because we will use a thread to batch and flush logs, which would not work in e.g. WASM environments.
• After we are good on the API, we can remove UNSTABLE and make it just logs in a future release.
• According to the spec, an additional init option enable_logs was added to enable sending them.

Note that this is not the final API.
The final API will come in a follow-up PR and will be similar to that of tracing, using macros for each level and taking in message and attributes.
Example: sentry::logger::warn!(my.attribute = 42, "structured warning: {}", "something");

Closes #798
Comes after #821

[codecov]

Codecov Report

Attention: Patch coverage is 52.84553% with 58 lines in your changes missing coverage. Please review.

Project coverage is 72.61%. Comparing base (7abbb38) to head (ab64707).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #823      +/-   ##
==========================================
- Coverage   72.94%   72.61%   -0.34%     
==========================================
  Files          63       63              
  Lines        7477     7598     +121     
==========================================
+ Hits         5454     5517      +63     
- Misses       2023     2081      +58     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lcian]

We cannot do this at the moment because sentry-contexts adds those through an event processor, which logs don't go through.

[Swatinem]

So this is what all other SDKs are doing? IMO it might be a bit wasteful to copy the same fields into the log event for every single log event.

In the likely case that users are not logging any attributes, this will allocate a hashmap, and clone at least 4 * 2 Strings into it. That is quite some overhead.

[lcian]

Yeah that's true. Unfortunately this is what the spec mandates, every single log should have these default attributes.

[lcian]

Do you see any way of optimizing it? @Swatinem
Maybe we could pre populate a Map with some of the default attributes and store it somewhere to reuse it, but we would still need to clone it for every log.

[Swatinem]

I was thinking about using a more optimized string type (like my own https://docs.rs/smol_buf/latest/smol_buf/) that can avoid clones in favor of refcounting or small string optimization.
That would cut down on memory usage and allocations a bit. Though the hashmap might still be heavyweight, and hard to avoid.

Not sure these things are worth the effort though? Considering that those would appear everywhere in public types, so it would likely cause some pain for users as well.

[lcian]

Yeah, I don't know.
I was also thinking of optimizations using Cows, providing special fields to store the default attributes that would take in a Cow. This way we wouldn't clone.
But the special fields would need to be pub anyway, because the struct lives in sentry-types.

[lcian]

I think we can merge it as is for now and we can always think about optimizing in the future.
However I agree it kinda sucks we need to attach this to every single log.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against ab64707