deer: implement Deserialize for &[u8]

[indietyp]

🌟 What is the purpose of this PR?

Implements deserialize for &[u8] to allow for borrowed byte slices, taken from #1875

🔗 Related links

• GEN-160: deer type implementation #1700
• deer implement Deserialize for built-in types (Part 2)  #1875

🔍 Has this modified a publishable library?

This PR:

• modifies an npm-publishable library and I have added a changeset file(s)
• modifies a Cargo-publishable library and I have amended the version
• modifies a Cargo-publishable library, but it is not yet ready to publish
• modifies a block that will need publishing via GitHub action once merged
• does not modify any publishable blocks or libraries
• I am unsure / need advice

[codecov]

Codecov Report

Merging #2389 (891e731) into main (a92b712) will increase coverage by 4.11%.
The diff coverage is 46.66%.

@@            Coverage Diff             @@
##             main    #2389      +/-   ##
==========================================
+ Coverage   56.76%   60.88%   +4.11%     
==========================================
  Files         336      318      -18     
  Lines       26012    24265    -1747     
  Branches      421      421              
==========================================
+ Hits        14766    14774       +8     
+ Misses      11241     9486    -1755     
  Partials        5        5              

Flag	Coverage Δ
backend-integration-tests	3.66% <ø> (ø)
deer	69.15% <46.66%> (-0.07%)	⬇️
unit-tests	1.49% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
libs/deer/src/impls/core/bytes.rs	46.66% <46.66%> (ø)

... and 23 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[thehabbos007]

Do you have any ideas for how we could handle this in JSON Schema? And would it be problematic for us to be using &[u8] for JSON?

[indietyp]

&[u8] is invalid JSON; depending on the library, it is either rejected (JustJson) or strings that are not valid utf8 are passed as bytes (serde-json).

In the future, I plan to introduce a more robust system for schemas (project blueprint™️) that would solve this ambiguity by being agnostic over the output schema and having JSON-Schema be one of the output schemas.

For JSON-schema, specifically bytes data is typically encoded via contentEncoding (https://json-schema.org/understanding-json-schema/reference/non_json_data.html) so you would specify as encoding base64 and then deserialize into bytes.

[thehabbos007]

I think we can merge as-is still regardless of question above, but would like thoughts on it still :)