[BUG] WebJobs BlobTrigger Poison Queue account fallback not working as expected

[mathewc]

Library name and version

Microsoft.Azure.WebJobs.Extensions.Storage.Queues 5.3.7

Describe the bug

Issue originally reported here: #53464 (comment)

The current intended behavior for poison blob handling of the special "webjobs-blobtrigger" control queue is for the corresponding poison queue "webjobs-blobtrigger-poison" to be created in the "target" storage account, only falling back to the "host" storage account (AzureWebJobsStorage) if queues aren't supported (code here).

However, the fallback code here doesn't work currently because this code here doesn't do any check to verify that the target client is valid, it just uses it if it isn't null (which it never will be). Likely this code used to work before refactorings over the years.

Expected behavior

If the target account supports queues (i.e. isn't a blob only storage account), the poison queue should be created there. Otherwise we should fall back to the primary storage account (AzureWebJobsStorage).

Customers can also run into permissions issues even if the target account does support queues. E.g. as in the original issue description - the identity role assignments being used don't permit queues.

Actual behavior

We'll always attempt to create the blob poison queue in the target storage account.

Reproduction Steps

See description above.

Environment

No response