[EventHubs] Partition Manager uses Event Hubs namespace as a key

[kinelski]

Current implementations of InMemoryPartitionManager and BlobPartitionManager have three keys (all of them strings) to access content:

• Event Hub Name
• Consumer Group
• Partition Id

These changes include a fourth key, Fully Qualified Namespace (also a string), to avoid ambiguity when a single Partition Manager is being used by Event Processors in different namespace contexts.

The main changes include:

• Update PartitionOwnership class to include a namespace property.
• Update Checkpoint class to include a namespace property.
• Update PartitionContext class to include a namespace property.
• Update PartitionManager and its derived classes to make use of the new key when managing ownership.
• Update method calls in the code to support the aforementioned changes.
• Update PartitionOwnership.IsEquivalentTo extension method to take the new key into consideration when checking equivalence.
• Include 4 new related tests (2 for InMemoryPartitionManager, 2 for BlobPartitionManager).

[jsquire]

LGTM. A couple of minor thoughts around naming, based on conversations with the service team and internal consistency.

[jsquire]

Overall still looks good. Shivangi has some great call-outs around a bit of documentation tweaks that we probably want to include.

[ShivangiReja]

I think we should add a try catch block around the foreach loop because ContainerClient.GetBlobsAsync(options) can throw an error while fetching the list of blobs.

try {
 await foreach (var response in ContainerClient.GetBlobsAsync(options).ConfigureAwait(false))
            {
                -
                -
            }
            return ownershipList;
  } catch(err) {
    Log($"Error occurred while fetching the list of blobs: '{ err }'");
    throw err;
}

Similarly in updateCheckpoint() method we should throw the errors in catch blocks if any error occurs while updating the checkpoint for the partition. We shouldn't swallow the errors in this case(I believe we swallow these errors in Event Hubs, so it won't stop any process but we should throw from this library)

I know this is not related to your current PR but something to keep in mind

[kinelski]

Just took a note. That's something I definitely should revisit when updating the error handling and implementing the Event Processor logging.