DATAGO-74463: Add Dynamic Producer Destination to the binder

[Aryelmr]

Description

##Overview
This pull request introduces a change to enable Dynamic Producer Destination functionality in the Azure ServiceBus Binder. This feature allows users to specify message destinations dynamically at runtime by using the AzureHeaders.Name.

##Motivation
Currently, the ServiceBus Binder utilizes the DefaultMessageHandler which supports dynamic destination routing through the AzureHeaders.NAME header. The destination is determined based on the presence of this header in a message (LINK):

private String toDestination(Message<?> message) {
        if (message.getHeaders().containsKey(AzureHeaders.NAME)) {
            return message.getHeaders().get(AzureHeaders.NAME, String.class);
        }

        return this.destination;
    }

However, despite being able to specify a dynamic destination, the message production fails if the DefaultEntityType is not pre-set. This is because the system does not know the entity type (queue or topic) of the destination, and it checks for this setting here (LINK):

@Override
    public ServiceBusSenderAsyncClient createProducer(String name, ServiceBusEntityType entityType) {
        ProducerProperties producerProperties = this.propertiesSupplier.getProperties(name) != null
            ? this.propertiesSupplier.getProperties(name) : new ProducerProperties();
        if (entityType != null) {
            producerProperties.setEntityType(entityType);
        }
        return doCreateProducer(name, producerProperties);
    }

Without a default entity type, the producer creation process fails even if the destination name is dynamically provided.

##Solution
To resolve this issue, I have implemented a change to set the DefaultEntityType accordingly to the entity type specified in the workflow configuration by the user. This ensures that the dynamic destination feature can function correctly and the message to routed properly.

----------------------------------------------------------------//----------------------------------------------------------------

If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[github-actions]

Thank you for your contribution @Aryelmr! We will review the pull request and get back to you soon.

[Aryelmr]

@Aryelmr please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree company="Solace"

[Aryelmr]

@chenrujun @Netyyyy @saragluna @moarychan

Hello,
Is there something additional I should do to get the PR reviewed or I only get it review after some pipeline is done?
Just trying to understand the process.