feat: Implement Envelope::from_path and Envelope::from_slice

[kamilogorek]

The implementation is highly inspired by https://github.com/getsentry/relay/blob/master/relay-server/src/envelope.rs and it includes most its deserialization tests.

We do not handle unknown item types for now, as it would require significant changes in how serializing works and how we store the envelopes. Thus we decided to skip it, for now, to support only item types that sentry-rust implements and enhance this feature in the future.

This will be enough to unblock getsentry/sentry-cli#703 anywya.
Closes #381

[codecov-commenter]

Codecov Report

Merging #456 (8ba95a0) into master (799f211) will increase coverage by 0.22%.
The diff coverage is 92.50%.

❗ Current head 8ba95a0 differs from pull request most recent head 7f883b3. Consider uploading reports for the commit 7f883b3 to get more accurate results

@@            Coverage Diff             @@
##           master     #456      +/-   ##
==========================================
+ Coverage   80.43%   80.66%   +0.22%     
==========================================
  Files          73       73              
  Lines        8364     8441      +77     
==========================================
+ Hits         6728     6809      +81     
+ Misses       1636     1632       -4     

[Swatinem]

I’m a bit surprised any of this works, lol. Probably because it just skips all the item headers as something that is not parsable, and then parses the item payload itself. That in turn means you will have problems parsing an Attachment item, which I see is also missing a test, probably for that reason ;-)

Instead of using serde magic, it might be a better idea to manually parse/match the item headers. Might as well create a derive(Deserialize) ItemHeader type, which has at least a type field, and possibly a length as well. In order to support attachments, you would have to make your parser more sophisticated as well, as going by lines() will break for attachments.

[Swatinem]

Should we care about more optional attributes like sent_at, dsn, etc? Probably not now, since envelope "round-trips" are not really a goal for now.

[kamilogorek]

We would need to change to_writer as well to handle this, as we currently ignore anything else other than event_id.

[Swatinem]

Suggested change

#[allow(dead_code)]

We are using this, maybe we are not exposing the transitive users publicly?

[kamilogorek]

It was due to unused attachment_type. Fixed it by using the value from item header and implementing FromStr for an AttachmentType

[Swatinem]

Instead of having a mut offset and sub-slicing from the original slice all the time, we can just have mut slice and do a slice = slice.get(offset..)? after we read each item, and above in from_slice.
But it doesn’t really matter that much anyway.

[Swatinem]

This duplicated map_err is a bit annoying.

We could potentially make this serde_json::from_slice(payload).map(EnvelopeItem::Event), and an explicit Ok(EnvelopeItem::Attachment(…)) below.
That way we can move the .map_err(…)? outside the match. That can potentially improve readability.

[kamilogorek]

So much better now :)