[RFE] Protocol needs a backwards-compatible means of negotiating capability set

[vcaputo]

This was touched upon in discussion of #99 and seems like a prerequisite before we can land anything in that vein.

@kusma do you think abusing SET_ROW for negotiation is still the best path forward? Care to clarify how that would work if so?

[vcaputo]

I'd really like to get something in place to allow forward progress on protocol-additions upstream... getting retire track in there would especially be nice.

Wouldn't it be sufficient to just have the demo side initiate a version negotiation of sorts in an opt-in manner? Not something all connects/greets perform, but something the demo developer has caused deliberately as a way to promote the api usage to a versioned one.

Sure, legacy editors might crash who don't know what the new cmd initiating the version exchange is. But is that worth worrying about when it's something the demo developer using the tooling has deliberately caused to happen? Presumably they'll get their editor sorted out and supporting the protocol level they're trying to use.

This way we'd leave the as-is users alone, and any editors modified to support the new version exchange would just restrict their behavior to the legacy protocol in lieu of any version exchange initiated by the demo.

@kusma WDYT?