Format multiline comments using | in the YAML spec

[banool]

Currently if you have a comment like this above an endpoint using poem-openapi:

    /// Encode submission
    ///
    /// This endpoint accepts an EncodeSubmissionRequest, which internally is a
    /// UserTransactionRequestInner (and optionally secondary signers) encoded
    /// as JSON, validates the request format, and then returns that request
    /// encoded in BCS. The client can then use this to create a transaction
    /// signature to be used in a SubmitTransactionRequest, which it then
    /// passes to the /transactions POST endpoint.
    ///
    /// To be clear, this endpoint makes it possible to submit transaction
    /// requests to the API from languages that do not have library support for
    /// BCS. If you are using an SDK that has BCS support, such as the official
    /// Rust, TypeScript, or Python SDKs, you do not need to use this endpoint.
    ///
    /// To sign a message using the response from this endpoint:
    /// - Decode the hex encoded string in the response to bytes.
    /// - Sign the bytes to create the signature.
    /// - Use that as the signature field in something like Ed25519Signature,
    ///   which you then use to build a TransactionSignature.
    ///

It gets written to the spec like this:

description: "This endpoint accepts an EncodeSubmissionRequest, which internally is a\nUserTransactionRequestInner (and optionally secondary signers) encoded\nas JSON, validates the request format, and then returns that request\nencoded in BCS. The client can then use this to create a transaction\nsignature to be used in a SubmitTransactionRequest, which it then\npasses to the /transactions POST endpoint.\n\nTo be clear, this endpoint makes it possible to submit transaction\nrequests to the API from languages that do not have library support for\nBCS. If you are using an SDK that has BCS support, such as the official\nRust, TypeScript, or Python SDKs, you do not need to use this endpoint.\n\nTo sign a message using the response from this endpoint:\n- Decode the hex encoded string in the response to bytes.\n- Sign the bytes to create the signature.\n- Use that as the signature field in something like Ed25519Signature,\nwhich you then use to build a TransactionSignature.\n\nTODO: Link an example of how to do this. Use externalDoc."

But what would be better is this:

description: |
    This endpoint accepts an EncodeSubmissionRequest, which internally is a
    UserTransactionRequestInner (and optionally secondary signers) encoded
    as JSON, validates the request format, and then returns that request
    encoded in BCS. The client can then use this to create a transaction
    signature to be used in a SubmitTransactionRequest, which it then
    passes to the /transactions POST endpoint.

    To be clear, this endpoint makes it possible to submit transaction
    requests to the API from languages that do not have library support for
    BCS. If you are using an SDK that has BCS support, such as the official
    Rust, TypeScript, or Python SDKs, you do not need to use this endpoint.

    To sign a message using the response from this endpoint:
    - Decode the hex encoded string in the response to bytes.
    - Sign the bytes to create the signature.
    - Use that as the signature field in something like Ed25519Signature,
      which you then use to build a TransactionSignature.

I will look into how to make this happen myself, just opening an issue to track it.

[banool]

Seems like serde-yaml doesn't plan on supporting the choice, but perhaps would support a different default: dtolnay/serde-yaml#174. I'll make a PR when I get time.

[banool]

dtolnay/serde-yaml#292

[banool]

Okay seems like serde-yaml does do this, so something is strange on the Poem side. I'll investigate.

[dtolnay]

  [dependencies]
- serde_yaml = "0.8.24"
+ serde_yaml = "0.9"

[banool]

Ahh thanks @dtolnay, you're a lifesaver. I'll make a PR @sunli829.

[banool]

#352

[banool]

Done!