feat: Support storing Component Fork data in SocialDB

[charleslavon]

Context

Out of all of the MVP Notification types to be supported, Component Forks are the only event type which is not currently written on-chain.

We need to create a pattern of writing component fork events on-chain and integrate this with the near.org UI (and ideally integrated with tools like bos-cli-rs) such that when a user forks a component and submits the transaction to write the forked component, a payload is included which writes the forked data on-chain.

We can accomplish this by leveraging our socialdbmetrics.near account and write to its socialDB namespace each time a forked component is committed from the near.org gateway.

We need

1. To grant a group of individuals the ability to manage the socialdbmetrics.near namespace in socialDB.
2. These individuals manage the namespace via their ability to grant write permissions onto certain areas within the socialdbmetrics socialDB namespace to the near accounts of individuals representing tools like bos-cli-rs and gateways such as and near.social.
3. A permissionless way to request accommodations from the individuals managing socialdbmetrics.near, e.g. request that a new gateway be granted the ability to write into a socialdbmetrics namespace
4. To restrict write permissions to specific areas within the socialdbmetrics.near socialdb namespace. Such that we can grant alice.near the ability to write into socialdbmetrics.near/post/near.org, while alice.near is denied write access in socialdbmetrics.near/post/bos.gg

Technical approach

The management functionality can be satisfied by two contracts.

1. A namespace-permission-managemment contract, for example deployed at permissions.socialdbmetrics.near, which provides the following api:
2. create_namespace(postNamespace): creates a new namespace at socialdbmetrics.near/post/[postNamespace]
3. grant_write_permissions(publicKey, postNamespace): stores the publicKey into an allowlist of namespaces and the accounts which have the ablity to write to them.
4. set(postNamespace, data): checks the allowlist and returns a permissions error if the publickey associated to the function call is not included in the associated postNamespace map. Otherwise, it writes the data payload into socialdbmetrics.near/post/[postNamespace]
5. bos-cli-rs In order to support collecting fork statistics from any user or automation which leverages bos-cli-rs, bos-cli-rs should be updated to support an explicit fork method, and include metadata indicating that a component has been forked.
6. a sputnikDAOv2 contract deployed at genesis.socialdbmetrics.near. The Dao contact would allow voting and multi-party agreement between the individuals that will manage socialdbmetrics.near (e.g. council members) on for example, who should allowed to write to socialdbmetrics.near namespaces.

{ socialdbmetrics: {
          post: {
            "near.org": 
            {
              "near/widget/NestedDiscussion.Compose": 
              {
                    "forks": 13,
                    "forks_detail": [
                        {
                            "blockHeight": 1234556,
                            "forkedTo": "alice.near/widget/NestedDiscussion.Compose"
                        },
                        {
                            "blockHeight": 871231,
                            "forkedTo": "bob.near/widget/NestedDiscussion.Compose"
                        },
                    ]
                },
              "alphaadmin.near/widget/NearOrg.HomePage": {
                  "forks": 2,
                  "forks_detail": [
                      {
                          "blockHeight": 1234556,
                          "forkedTo": "alice.near/widget/AliceBookStore"
                      },
                      {
                          "blockHeight": 871231,
                          "forkedTo": "bob.near/widget/BobsGarageSale"
                      },
                  ]
                      }
                  }
              }
              "bos-cli-rs": {
               },
                "bos.gg": {
                    ....
                },
                "near.social": {
                    ....
            }
          }
        }
    }

Questions

1. Are socialdB's namespace permissions granular enough to manage permissions for distinct post types? E.g. can we allow a publickey reprsenting 's UI to write to socialdbmetrics.near/post/near.org and not be able to also write to socialdbmetrics.near/post/bos.gg? Or can permission only be managed at the parent 'post' level?
   No, this is not possible on socialDB directly. To accomplish this would require a contract (e.g. permissions.socialdbmetrics.near) which enforces said restriction in an interface to socialDB's set function.

[charleslavon]

Closing this in favor of a more simplified approach #341