Feat/nico/likes sync

[NicoSerranoP]

This PR covers a couple of things:

1. syncs the likes (user related such as likedContent and content related such as likes) directly with each user or content object.
2. standarizes some data naming
3. fixes tags and likes EIP signatures (and its tests) so they cover timestamp as well

[jp4g]

Is there an explicit reason only the backend can "charge the vault"? It is unlikely people will randomly donate but if they wanted to fund the vault, is there a downside to allowing them?

[jp4g]

When syncing, is it the responsibility of the backend to make sure the # of likes for some content has parity with the actual likes stored by each user? Is there a way to litigate a discrepancy in likes between these two sources of truth/ is one THE source of truth?

[NicoSerranoP]

Is there an explicit reason only the backend can "charge the vault"? It is unlikely people will randomly donate but if they wanted to fund the vault, is there a downside to allowing them?

The slashing vault is only rechargable by the backend because it is the staked value that the backend puts as a guarantee. If a user proves a receipt was not included in the contract, the user would get rewarded from this slashing vault.

[NicoSerranoP]

When syncing, is it the responsibility of the backend to make sure the # of likes for some content has parity with the actual likes stored by each user? Is there a way to litigate a discrepancy in likes between these two sources of truth/ is one THE source of truth?

It is the backend responsibility to keep the number of likes in each content and the user likes align. There is one litigation function that any user could call that would perform a check on a specific content likes vs which users have liked the content. The function name is litigateNumberOfLikes