migrate SDKs to use generated services

[cataggar]

The goal is to have the SDKs use the generated services. Ideally, they are a thin layer on top. Previously brought up in #717.

• [ ] azure_iot_deviceupdate on top of azure_svc_deviceupdate

  • 733

• [ ] azure_data_cosmos on top of azure_svc_cosmosdb
• [ ] azure_security_keyvault on top of azure_svc_keyvault
• [ ] azure_storage_blobs on top of azure_svc_blobstorage
• [ ] azure_storage_datalake on top of azure_svc_storagedatalake
• [ ] azure_storage_queues on top of azure_svc_queuestorage
• [ ] auzre_messaging_eventgrid on top of azure_svc_eventgrid

  • 1451

There are several issues for the generated crates that need to be resolved before this will be possible.

• 446

• 174

• 649

[johnbatty]

Do you have an example of how the SDK crates improve the API/interface compared to the autogenerated crates? In other words, what do you expect the "thin layer" to be doing?

[cataggar]

Not yet, we were going to try to figure that out as part of #733.

[mario-guerra]

@cataggar will the service bus crate be included in this effort?

[ctaggart]

@mario-guerra, there is not a generated azure_svc_servicebus crate because the Service Bus Runtime REST API does not have a published specification https://github.com/Azure/azure-rest-api-specs/issues/16429. If it was documented, would we have a REST API implementation and an AMQP implementation of overlapping functionality? There has been some recent work geting an AMQP implemeantion to work with Service Bus in https://github.com/Azure/azure-sdk-for-rust/issues/643 by @minghuaw.