Event Grid Namespaces client (tracking)

[richardpark-msft]

Just filing some of the issues that have come up when auto-generating an Event Grid client:

• To accomodate the multitude of packages we're going to have for Event Grid
  we're going to move 'azeventgrid' to create space for a new package
  (Event Grid Namespaces) and to split out system events into their
  own package (azsystemevents). This also implies we'll have to create publishing pipelines for each of those areas.
• Authentication header format is SharedAccessKey <shared key. I'm able to use a PerRetry policy to add this but we do need a credential type for this. It appears other libraries have defined a custom credential type for their individual packages.
  • Appears the final decision was to auto-generate a policy that inserts this, which seems similar to what I did manually. Ex: Support generating ApiKey with prefix  autorest.typescript#1870
• PublishCloudEvents is supposed to set the Content-Type to application/cloudevents-batch+json; charset=utf-8, but instead just sets it to application/json.
• Create a CloudEvent type into azcore, for use with messaging SDKs #20970
• There are some fields in CloudEvent that have to be filled out but I'm not sure if there's intended to be a constraint or not, as other languages don't seem to require them all (and are probably filling them out with defaults). (Specversion, ID)
• ClientPublishCloudEventsResponse an embedded field called Interface of type any:

  // ClientPublishCloudEventsResponse contains the response from method Client.PublishCloudEvents.
  type ClientPublishCloudEventsResponse struct {
    // Anything
    Interface any
  }

• AcknowledgeCloudEvents has an argument that represents the lockTokens but the type is AcknowledgeOptions:

     AcknowledgeCloudEvents(ctx context.Context, 
       topicName string, 
       eventSubscriptionName string, 
       // <-- This parameter here --> 
       lockTokens AcknowledgeOptions, 
       options *ClientAcknowledgeCloudEventsOptions)

• ReceiveCloudEvents has an explicit MaxWaitTime parameter. It's possible for us to say "we can just use the deadline of the context" but we might need some wiggle room, as the "timeout" in this case is actually a response from the service.
• When receiving the CloudEvent the 'Data' field appears to be a base64 encoded version of the data, rather than just being whatever the data was (in my case, it was a string).
  --
  Note these all came out of the client generated from this rev of the swagger: link

[richardpark-msft]

Going to close this out as the one outstanding issue (supporting binary mode) is filed as it's own standalone issue (#22304)