azure: Invalidate storage client if storage account name changes

[jshearer]

We ran into this when a customer changed their storage account name. Fragment listings for their journal were returning errors complaining about resolving the hostname of the previous storage account, even through the fragment spec correctly specified new storage account name.

---

This change is 

[jgraettinger]

is this ready for review?

[jshearer]

No, I've been having all sorts of trouble getting a local stack working so I haven't managed to test this yet :/

[jshearer]

@jgraettinger Okay, finally got my local stack un-broken and validated both that I could reproduce the original problem, and that this fixes it.

• Start out with a storage mapping like so:

  {
      "provider":"AZURE",
      "storage_account_name":"account_a",
      "container_name":"data",
      "prefix":"collection-data/",
      "account_tenant_id":"1234"
  }
  

• Create a hello world capture with a short flushInterval
• Fragments start showing up in account_a, and signed URLs work correctly
• Add a new storage mapping to a different Azure storage account in the same tenant, keeping the old storage mapping around:

  {
      "provider":"AZURE",
      "storage_account_name":"account_b",
      "container_name":"data",
      "prefix":"collection-data/",
      "account_tenant_id":"1234"
  },
  {
      "provider":"AZURE",
      "storage_account_name":"account_a",
      "container_name":"data",
      "prefix":"collection-data/",
      "account_tenant_id":"1234"
  }
  

• Re-publish the capture task
• This is what was broken: New fragments are written to the new storage account, but signed URLs for fragments in account_b generate the following error:

  <Error>
      <Code>AuthenticationFailed</Code>
      <Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:8dca77fa-f01e-006a-66fe-507415000000 Time:2024-12-18T03:39:16.6155395Z</Message>
      <AuthenticationErrorDetail>Signature did not match. String to sign used was r 2024-12-18T04:39:13Z /blob/josephtesting/data/collection-data//test/test-9/events/0fa82ffc2c80001e/pivot=00/utc_date=2024-12-18/utc_hour=03/00000000000107e6-00000000000149f7-84bb727e5669067a87a19b31add965ff6f155ef0.gz a40cc9be-df7e-4ac1XXXXXXXXXXXXXXXXXX b668bb48-8340-473a-acb7-72103f4f0b09 2024-12-18T03:27:30Z 2024-12-24T03:27:40Z b 2020-10-02 https 2020-02-10 b </AuthenticationErrorDetail>
  </Error>
  

• Now, if I swap my Gazette version for the one in this pull request and repeat the above steps, after adding the second storage mapping and re-publishing, signed URLs generated for fragments written to both storage mappings all work as expected.

[jgraettinger]

LGTM