[ENHANCE] Correctly save and retrieve NEAR Social data on project registration & update

[lachlanglen]

Title

Correctly save and retrieve NEAR Social data on project registration & update

Summary

Items being incorrectly stored:

1. name - should be populated from NEAR Social data if available

2. category - this should be renamed to potlockCategories and instead of an array, should be formatted as per as per NEAR Social Tags schema: an object with category name as key and empty string as value (just like how team is currently being stored). E.g. if I have "Social Impact" and "Non Profit" categories selected, the value should look like

{
  ...,
  "profile": {
    ...,
    "potlockCategories": { "Social Impact": "", "Non Profit": "" }

3. image and backgroundImage - these are currently being saved as

"backgroundImage": {
  "ipfs_cid": "cid from ipfs"
},
"image": {
  "ipfs_cid": "cid from ipfs"
}

which obviously is not correct. Value should be populated as follows:

• If user uploads images, should use CIDs of uploads
• Otherwise, should use existing near.social data for this user

Both values must be of type Image

4. Smart Contracts & Funding Sources

This data is not being saved at all currently. Please determine the best format to save these in and run it by @lachlanglen before implementing.

They should live on near.social at profile.contracts and profile.fundingSources respectively.

5. Social Links

Any social links that have been updated from what is on NEAR Social should be included in data saved to near.social.

Overall

• Populate data correctly from NEAR Social
• Save data correctly to NEAR Social

NB: Across all fields, avoid storing redundant data (keys whose values have not changed from what is currently saved on NEAR Social) as this just increases required transaction deposit for user.

Motivation

[More detailed explanation of the motivation for the enhancement, including any benefits it would provide]

Description

[Detailed description of the enhancement, including how it would work and any design considerations]

Alternatives

[Discussion of any alternative solutions that were considered and why the proposed solution is preferred]

Risks

[Identification and mitigation of any potential risks associated with the enhancement]

Acceptance Criteria

[List of criteria that must be met for the enhancement to be considered accepted]

Additional Information

[Any other relevant information, such as links to related issues or pull requests]