Remove `serde_norway` dependency

[juhaku]

Remove the serde-norway dependency and use the yaml-serde solely the only yaml provider. This will be a breaking change.

Current implementation

#[cfg(feature = "yaml")]
#[cfg_attr(doc_cfg, doc(cfg(feature = "yaml")))]
pub fn to_yaml(&self) -> Result<String, serde_norway::Error> {
    serde_norway::to_string(self)
}

/// Converts this [`OpenApi`] to YAML String. This method essentially calls [`yaml_serde::to_string`].
#[cfg(feature = "yaml_serde")]
#[cfg_attr(doc_cfg, doc(cfg(feature = "yaml")))]
pub fn to_yaml_serde(&self) -> Result<String, yaml_serde::Error> {
    yaml_serde::to_string(self)
}

New implementation after removing serde-norway

/// Converts this [`OpenApi`] to YAML String. This method essentially calls [`yaml_serde::to_string`].
#[cfg(feature = "yaml")]
pub fn to_yaml(&self) -> Result<String, yaml_serde::Error> {
    yaml_serde::to_string(self)
}

Ref #1559

[CommanderStorm]

There also is https://docs.rs/serde-saphyr/ which according to https://users.rust-lang.org/t/new-serde-deserialization-framework-for-yaml-data-that-parses-yaml-into-rust-structures-without-building-syntax-tree/134306 has better performance due to eliminating the intermediate allocations...

I would stil argue for to_yaml_serde, but in the end this could also be an mutually exclusive feature or saphyr could be named differntly..

[BjarneSeger]

That crate looks promising as well, both the additional performance as well as the security aspects (which I don't know very much about in yaml_serde, only that they basically did not change from the original serde_yaml).
I'd just question two things:

• How well will it be maintained in a year compared to a crate from the yaml org (which may also not maintain their crates well, but may have more of an interest than an individual in doing so)
• How performance-critical is serializing your schema (since it will probably just be exported to somewhere once or should be cached anyway if you serve it from your server directly).
  Do you per chance have / know some project I could use for benchmarking both deserializers?

[juhaku]

Great crate for sure. @BjarneSeger yes, those are valid questions. And constantly changing implementations in the utoipa crate is not very appealing and honestly time not well spent.

At one point I was even considering of removing the yaml feature completely, as all it does is actually the 3 line function there, which is something that everybody could just implement their own using their preferred library. That would be better for utoipa to have less breaking dependencies.

Nonetheless support for both libraries could be considered. But rather having multiple functions like to_yaml to_yaml_serce etc. Perhaps leveraging traits would be a better fit. That is something to play around in future.

[BjarneSeger]

I don't think any extra traits (or even these builtin methods) are necessary since the OpenApi struct is already Serialize + Deserialize, so it's just a matter of serde_json::to_string(ApiStruct::openapi()) instead of ApiStruct::openapi().to_yaml(). As long as this is documented (and there is no internal serialization to yaml), there is no need for an included yaml parser.

[juhaku]

Yeah, you are right, I was thinking finding a way to hide method signature more over the specific error response. What I could do already with impl Error return instead. But with that you'd loose the type erasure of the error. Though with that you could downcast it to the actual type most likely. But it is not the most ergonomic way. But perhaps there is no way around it.