build: recognize collection_model_binding_data for batch inputs

[EvanR-Dev]

This pull request introduces several changes to enhance the handling of collection_model_binding_data. The most important changes include adding support for collection_model_binding_data in the datumdef.py and meta.py files
Enhancements to data handling:

• azure_functions_worker/bindings/datumdef.py: Added support for collection_model_binding_data in the from_typed_data method.
• azure_functions_worker/bindings/meta.py: Modified the deferred_bindings_decode method to handle collection_model_binding_data by accumulating the content of each model_binding_data. [1] [2]

Description

Addresses https://github.com/Azure/azure-functions-pyfx-planning/issues/393

---

Today when a user uses a deferred binding, the host sends a model_binding_data object that is converted into its corresponding SDK type. This object contains important information about the SDK type, but most notably the content.

For triggers that can handle batch inputs such as EventHub, this means the cardinality="many" - in this case, the host sends us a collection_model_binding_data object, which is just 1 to N model_binding_data objects. Here is a sample for each:

model_binding_data:

version: "1.0"source: "AzureEventHubsEventData"content_type: "application/octet-stream"content: "\000Sr\301\216\010\243\033x-opt-sequence-number-epochT\377\243\025x-opt-sequence-numberU.\243\014x-opt-offset\201\000\000\000\001\000\000\030\020\243\023x-opt-enqueued-time\000\243\035com.microsoft:datetime-offset\201\010\335c/`\215c\220\000St\301I\002\241\rDiagnostic-Id\241700-2b9c74c8f8a49fcdee7743b26534811a-891cfa411389e551-00\000Su\240 {\"message\": \"Hello from local!\"}"

collection_model_binding_data:

model_binding_data {
  version: "1.0"
  source: "AzureEventHubsEventData"
  content_type: "application/octet-stream"
  content: "\000Sr\301\216\010\243\033x-opt-sequence-number-epochT\377\243\025x-opt-sequence-numberUH\243\014x-opt-offset\201\000\000\000\003\000\000\006\340\243\023x-opt-enqueued-time\000\243\035com.microsoft:datetime-offset\201\010\335e\266\360\233G\300\000St\301I\002\241\rDiagnostic-Id\241700-a6e861768b42bdbaa26e5e367c8b0ffa-d71a437aea587458-00\000Su\240 {\"message\": \"Hello from local!\"}"
}
model_binding_data {
  version: "1.0"
  source: "AzureEventHubsEventData"
  content_type: "application/octet-stream"
  content: "\000Sr\301\216\010\243\033x-opt-sequence-number-epochT\377\243\025x-opt-sequence-numberUI\243\014x-opt-offset\201\000\000\000\003\000\000\007\220\243\023x-opt-enqueued-time\000\243\035com.microsoft:datetime-offset\201\010\335e\266\360\233G\300\000St\301I\002\241\rDiagnostic-Id\241700-a6e861768b42bdbaa26e5e367c8b0ffa-d71a437aea587458-00\000Su\240 {\"message\": \"Hello from local!\"}"
}

Notice that model_binding_data automatically has the fields accessible to do the conversion whereas collection_model_binding_data has each model_binding_data nested

From proto:

// Used to encapsulate collection model_binding_data
message CollectionModelBindingData {
  repeated ModelBindingData model_binding_data = 1;
}

// Message representing Microsoft.Azure.WebJobs.ParameterBindingData
// Used for hydrating SDK-type bindings in out-of-proc workers
message ModelBindingData
{
    // The version of the binding data content
    string version = 1;

    // The extension source of the binding data
    string source = 2;

    // The content type of the binding data content
    string content_type = 3;

    // The binding data content
    bytes content = 4;
}

PR information

• The title of the PR is clear and informative.
• There are a small number of commits, each of which has an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
• If applicable, the PR references the bug/issue that it fixes in the description.
• New Unit tests were added for the changes made and CI is passing.

Quality of Code and Contribution Guidelines

• I have read the contribution guidelines.

[swapnil-nagar]

NIT: Improvement suggestion:

validSources = {
"AzureEventHubsEventData",
"AzureServiceBusReceivedMessage"
}

if datum.type == "collection_model_binding_data" or datum.value.source in valid_sources:
return binding.decode(datum, trigger_metadata=metadata, pytype=pytype)

Also, can type can be enum in your datum model? That will avoid the string comparisons and improve the codebae as less strings constant will flow.