Support Composite and Routing metadata APIs

[rstoyanchev]

Now that RSocket Java has CompositeMetadataFlyweight and RoutingMetadata/TaggingMetadataFlyweight based on the corresponding extensions, it would be useful if the CLI could support sending metadata encoded with those APIs.

Not sure how this works out into command line arguments, but for composite it's essentially multiple sets of metadataFormat and metadata pairs. For routing, a collection of tags.

[yschimke]

What would a sample command look like? Something easy to type I guess.

[rstoyanchev]

Sorry, I missed this comment..

I wasn't too sure about the difference between -h and -m initially but now I tend to think it could be that if you do -m multiple times then that's encoded with composite metadata. Of course metadataFormat would need to be a List too. It would get verbose to say --metadataFormat many times. Maybe this command line option accepts a list format?

[yschimke]

@rstoyanchev I like that idea, makes a lot of sense. The order must match then between types and the metadata payloads. So we could also consider some way to combine those? e.g. type:payload?

But your suggestion works for me.

[rstoyanchev]

I wonder if @ArgGroup could help to enforce a sequence of --metadataFormat -m pairs which I think would provide sufficient structure.

I also notice support for maps, which could support --metadataEntry key value pairs like this:

-me application/foo="..." -me application/bar=@file -me ...

If we choose the latter, which I tend to like because it combines pairs naturally and is much shorter to type, I think it would make sense to avoid supporting both --metadataFormat + -m as well as a sequence of -me. Ideally it would be just -m key-value pair(s) but I'm not sure what the backwards compatibility expectation are. Adding -me or similar and deprecating -m could be another option.

[yschimke]

No backwards compatibility. Design what makes sense for any firm requirements. The current impl is mostly for debugging.

[yschimke]

Added --route in #91

Some potential cleanup in https://github.com/rsocket/rsocket-cli/pull/92/files