feature: Derive Display for all aries messages

[Patrik-Stas]

• Derives Display trait for all aries messages
• Removed default Decorators type parameter D = NoDecorators - turned out somewhat problematic in conjunction with the custom Display proc macro. Not a big price to pay though, only slightly inconveniences developer working in messages crate, but not messages consumers.

[codecov-commenter]

Codecov Report

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

Comparison is base (6e718c2) 0.05% compared to head (a861b63) 0.05%.

Files	Patch %	Lines
aries/messages/src/msg_parts.rs	0.00%	2 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1069   +/-   ##
=====================================
  Coverage   0.05%   0.05%           
=====================================
  Files        471     471           
  Lines      24009   24009           
  Branches    4306    4294   -12     
=====================================
  Hits          13      13           
  Misses     23995   23995           
  Partials       1       1           

Flag	Coverage Δ
unittests-aries-vcx	0.05% <0.00%> (ø)

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

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

[nain-F49FF806]

I can't comment on display_as_json code, as that's beyond my understanding, but other than that, LGTM!

[mirgee]

Can you please specify the problem that the default type was causing?

[Patrik-Stas]

Prompted me to dig into this more - the issue was the proc macro was too simplistic, it was generating stuff like

impl<C, D = NoDecorators> std::fmt::Display for MsgParts<C, D>
    where
        C: serde::Serialize,
        D: serde::Serialize,

while is should had been

impl<C, D> std::fmt::Display for MsgParts<C, D>
    where
        C: serde::Serialize,
        D: serde::Serialize,

This is addressed now, syn crate has useful function split_for_impl available for Generics type, which allows to work with the generics related statements in more granular fashion.

So I am re-introducing the default NoDecorators type, reverting some of the changes done here

[mirgee]

I hope that the fact that the decision to rather modify the sites of usage instead of fixing the macro seemed as a better approach is more about due to skill issue rather than the fact that procedural macros are on harder to maintain :) Probably both, though...

[Patrik-Stas]

@mirgee I think you misunderstood me, I fixed the macro. No change to callsites anymore

[mirgee]

@Patrik-Stas No, I am talking about the initial decision (hence the past tense there).

[Patrik-Stas]

Ah yeah. In fact I misread. Indeed exactly as you said, it's definitely objectively better to make the macro more robust.