Consider separating JSON for connection and payload

[pac-work]

Reuse of the same JSON structure for both the connection and as the description accompanying actual data seems ambiguous. Some fields are related to the current state and are relevant for the payload JSON and do not seem to be relevant for the connection phase. These two JSONs should be separated and clearly defined using JSON Schema or similar mechanism (mandatory vs. optional fields, etc.). Not doing so will result in different implementations by different vendors not being compatible. I see it improved since my last reading - now the text contains some information regarding this, but still not exact enough. Separation on the GitHub page in the README.md would help a lot.

Examples:

• "These values must not change over the lifetime of the connection except as noted below" on the timing section, but section contains COT and LAT...
• payload_json_str saying "media: ... ## Same as connection's media array. ##", but that contains just "mediaFlow", so what is right?

[mhhen]

Will remove the JSON from the README.md and reference new JSON schema files as described below:

connection_schema.json - Schema used by the connection APIs - GccgTxConnectionCreate() and GccgRxConnectionCreate(). ret_connection_schema.json - Schema returned after invoking the connection APIs. payload_schema.json - Schema used by the GccgTxPayload() and GccgRxCallback() APIs.

[pac-work]

Thank you very much, the schemas are great improvement.