capture the full raw response for Reply/Notificaiton
While working with an internal netconf service I discovered that OKResp and other structs were not being parsed properly. This is because xml (and thus encoding/xml) is document focused. An XML document has single root. This means the "defered" parsing of the <rpc-reply> body doesn't work as you need a proper root node (not just a value) as well you cannot support multiple nodes.
To fix this, begrudgingly, this change changes the API to to not just expose the Body to the call but the entire <rpc-reply> to be parsed. The same goes for <notification>.
This could mean slightly larger allocations, but really.... it doesn't matter. The majority of the data would be inside the Body value anyway so adding the wrapping <rpc-reply> doesn't add much.
I think there is room in a v2 to explore a full stream based solution here, but not needed for this. It does make the full io.Reader/io.Writer of RFC6242 kinda.. worthless now, but perhaps this will make things like netconf over QUIC possible. We will see.
Closes: #62
Breaking changes
- Reply.Body and Notification.Body are now gone. In their place there is a
Raw()andString()methods on both structs to return the raw data and a string representation. - OkResp was renamed to OKReply
- GetConfigReply was reworked to assume
as the base.
I think there is future work to make a <rpc-reply> drop in for structs to enforce the root node, but this works for now.