feat: unwrap jsonschema one level

[grant]

Fixes #72

• Unwraps the JSON Schemas one level to directly access the data as seen in the JSON payload from events.
• Very light formatting
• Does not modify contents of schema (even though diff looks weird)

Will make the Node types a bit simpler to gen.

[grant]

Chen voiced some concern about this due to some schemas having multiple types.

I'll have to look further here.

[grant]

Hey folks, can you review and add comments here?

Looking today, I still think that Eventarc doesn't naturally produce these wrapper types.

Moreover, JSONSchema tooling doesn't work well since HTTP JSON payloads don't have the wrapper (like field MessagePublishedData).

This requires a developer to inspect their HTTP request, wrap in a { "SomethingData": { ...actual POST body }, which just isn't mirroring the results from Eventarc. I believe the JSON schemas shouldn't have this wrapper.

Tested schema locally.

[jskeet]

My position is as it was before: the JSON schema should probably follow what we use in the protos, i.e. publishing the data messages, but not the event messages (yet). That said, I don't know details of JSON schema restrictions or best practices.

For example, even if we did publish the code generated from event protos, that wouldn't actually change much for proto users - because the data protos would still be top-level types. Is there any reason why the data messages in the JSON schema are nested types rather than top-level types, assuming that's what actually happens?

[grant]

Follow that, the data message (seen with data protos) should follow the json schema, which this PR fixes.

[grant]

I'd expect this to work:

{
  "$schema": "https://raw.githubusercontent.com/googleapis/google-cloudevents/master/proto/google/events/cloud/pubsub/v1/schema.json",
  "message": {
    "data": "SGVsbG8gdGhlcmU=",
    "messageId": "1408577928008405",
    "publishTime": "2020-08-06T22:31:14.536Z"
  },
  "subscription": "projects/MY-PROJECT/subscriptions/MY-SUB"
}

Instead, you must do this, given the wrapped JSON Schema:

{
  "$schema": "https://raw.githubusercontent.com/googleapis/google-cloudevents/master/proto/google/events/cloud/pubsub/v1/schema.json",
  "MessagePublishedEvent": {
    "message": {
      "data": "SGVsbG8gdGhlcmU=",
      "messageId": "1408577928008405",
      "publishTime": "2020-08-06T22:31:14.536Z"
    },
    "subscription": "projects/MY-PROJECT/subscriptions/MY-SUB"
  }
}

[grayside]

I found this difficult to review without orienting on the before and after by checking what a complete schema document looks like from prior to this PR, https://github.com/googleapis/google-cloudevents/blob/af50141cea3707b98154535d5447d4ae69b968dd/proto/google/events/cloud/audit/v1/schema.json

[grant]

@michaelawyu Hey Chen, I'd like you to approve this PR before I merge.
The MessagePublishedEvent is supposed to represent the whole CloudEvent, including CE event fields. We don't want this in the JSON Schema because our events just have the raw data.

This will affect JSON Schema generators. We should get this in ASAP to make sure there isn't 1 extra level of wrapping.

[grant]

I think the main issue is supporting multiple types.

I think we're fine with a schemas/ directory such that each type will have its own schema.