feat(notification): add blob download meta object to notifications

Related to #961 & #962

Context

We want to expose (to consumers of the registry notifications):

• The storage backend that a blob was downloaded from OR the url provider (e.g googlecdn) that was used to redirect a blob download request

What is in this MR?

• A new attribute in the notification Event struct called Meta: This attribute can be used to populate non standard event attributes

For the specific case of blob download events (serviced by the registry's API via ServeBlob ) the event meta object will contain the following fields (as suggested in #961 and #962 ):

"blob":{
  "storageBackend": "s3aws|gcs|swift|azure|filesystem..."
  "redirected" : true|false
}

Full example payload sent to subscribers

{
   "events":[
      {
         "id":"6fdd1c74-381e-4f42-856e-09eb495d1588",
         "timestamp":"2023-05-04T10:01:21.181168-04:00",
         "action":"pull",
         "target":{
            "mediaType":"application/octet-stream",
            "size":341,
            "digest":"sha256:c8c412e0d7ad6c03bd1dfee589a5d9c9e4aa5db0e1436f2954511adc8dde26bf",
            "length":341,
            "repository":"test/bash",
            "url":"http://registry.test:5000/v2/test/bash/blobs/sha256:c8c412e0d7ad6c03bd1dfee589a5d9c9e4aa5db0e1436f2954511adc8dde26bf"
         },
         "request":{
            "id":"d0f54cd8-3d68-444a-b0f8-c164b753f22a",
            "addr":"127.0.0.1:52088",
            "host":"registry.test:5000",
            "method":"GET",
            "useragent":"docker/20.10.17 go/go1.17.11 git-commit/a89b842 kernel/5.10.124-linuxkit os/linux arch/arm64 UpstreamClient(Docker-Client/20.10.17 \\(darwin\\))"
         },
         "actor":{
            
         },
         "source":{
            "addr":"Suleimis-MacBook-Pro.local:5000",
            "instanceID":"1832c4c3-4aec-4fd8-9479-5c581dfe0f1d"
         },
         "meta":{
            "blob":{
               "redirected":true,
               "storageBackend":"s3aws"
            }
         }
      }
   ]
}

Note The blob meta object is also sent downstream to the handlers (but is unused at the moment) in preparation for tackling #824 (see here)

What is not in this MR

• There's a fair bit of change required in the codebase to identify the redirect url provider (in the case a blob download request was redirected and not downloaded directly using the storage driver). I've opted for the MVC here by instead returning the configured storage driver's as the storageBackend in all cases AND if the request was redirected or not (in the redirected field).

I've opened a separate issue here to tackle introducing the functionality to determine the redirect url provider.

• Refactoring the BlobPulled event notification system to be emitted from the handlers -> #824