Add all forwarding schemars JsonSchema impls

[swlynch99]

Following up where #666 left off, this adds all the JsonSchema impls for serde_with adapters whose implementation can be just a forward_schema!(...). I have also included test cases covering most of the new impls. These are mainly snapshot tests since those are the easiest to write but where appropriate I've included more detailed tests.

Detailed Changes

• Implemented JsonSchema for BorrowCow, Bytes, DefaultOnError, DefaultOnNull, FromInto, FromIntoRef, TryFromInto, TryFromIntoRef, Map, MapFirstKeyWins, MapPreventDuplicates, SetLastValueWins, SetPreventDuplicates, StringWithSeparator, and VecSkipError.
• Added tests covering most of these
• Snapshot tests now have a trailing newline

The only non-forwarded implementation is SetLastValueWins. It was originally forwarded but after looking at the snapshot I realized that wasn't quite right.

Open Questions

• DefaultOnError can technically take any json value as input. I haven't done this so far but you could represent this as

  {
      "any_of": [
         "<schema for T>",
         { "write_only: true" }
      ]
  }

  which would specify that, when serializing, we use the schema for T, but when deserializing it could be either the schema for T or literally anything. I don't actually think that this is very useful to do so I haven't included it but it is an option. The same question applies to the elements of VecSkipOnError.

[codecov]

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (d2fc3a4) 65.26% compared to head (78d771d) 65.24%.

Files	Patch %	Lines
serde_with/src/schemars_0_8.rs	57.14%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #676      +/-   ##
==========================================
- Coverage   65.26%   65.24%   -0.02%     
==========================================
  Files          38       38              
  Lines        2240     2256      +16     
==========================================
+ Hits         1462     1472      +10     
- Misses        778      784       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jonasbb]

I think the implementation of DefaultOnError by forwarding to T is fine. When serializing you always get the behavior of T. When deserializing you expect a T, but you are willing to handle other data. It could be considered as accepting anything for deserialization. If that duality can be modelled, it could be considered. I took a quick look at JSON schema and the writeOnly annotation, since you suggested it. The examples I saw used it slightly different, but I am not familiar with JSON schema to judge that enough.
The same reasoning applies to VecSkipOnError, so treating it equivalent to Vec<T> seems ok.

[jonasbb]

I'm curious, what is your plan with the support here? Do you want to extend the JsonSchema for most/all of the already existing transformations in this crate? For example, instead of Map you can use BTreeMap or HashMap, and the inverse exists as Seq.
No commitment is necessary here :) But I am happy to release the code as beta/3.5.0 or see about collaboration in this repo.

[swlynch99]

My plan was to at the very least submit everything in https://github.com/swlynch99/serde_with/tree/schemars-full. That includes a JsonSchema impl for every exported type in this crate that implements SerializeAs and DeserializeAs. I figure if I'm going to do this it's better for me not to do it halfway :)

Having a new release with that includes this PR would be nice since most of the parts I need are included in this one. That being said, I will be continuing to submit the rest of the code in that branch one bit at a time.

I took a quick look at JSON schema and the writeOnly annotation, since you suggested it. The examples I saw used it slightly different, but I am not familiar with JSON schema to judge that enough.

My main use case in using jsonschema is for generating OpenAPI specifications in which case writeOnly and readOnly map pretty much exactly to "this is only valid for the request" and "this is only valid for the response". This seems to match other people's interpretations. I'm not an expert on json schema either but from looking around a bit writeOnly and readOnly` end up mostly being ignored in other contexts (e.g. validation).

I do agree that this doesn't really make sense to do for DefaultOnError and VecSkipError so I don't think there's anything to do here. It will, however, come up again in my PR for PickFirst and a few other cases. In that case I think having the writeOnly variants is better than only having the first one.

[jonasbb]

Ok, that sounds good. I will prepare a release with the code including #679.