Ensure API can't be tricked into returning manipulated data

[efstajas]

Since we're dealing with an open protocol, malicious users could theoretically send transactions from outside the Drips App with the aim of displaying incorrect splits on their Projects or Drip Lists, while a different splits config is applied on-chain. In order to prevent this, we need to ensure that the API never returns any splits that don't currently exist on-chain.

Some considerations below - this is just a brain dump, and it's likely that some of these are already solved within the code - if this is the case, please lmk!

• When writing forge info for GitProject recipients on-chain and metadata has to be used to source the project's forge info (name, url etc.), always validate that info against the recipient project's user ID. Same approach as what we're already doing in the app today – since the user ID includes hashed project info, we can always definitively validate that metadata describing a split to a particular project hasn't been altered in order to e.g. display the name of a completely different project.
• We can't only source splits info from metadata. If we would, users could create malicious batch transactions that mimic those triggered from the app, but actually include metadata that lists additional splits that don't exist in the setSplits call. For this reason, we need to always make sure that any split listed in metadata actually also exists on-chain (can be done by verifying the splits receiver hash?)
• Updates to splits of Drip Lists and Projects triggered from within the app are always accompanied by a metadata update, so we need to be wary of lone setSplits events. If we ignore such events, malicious actors could create a state in which the project / drip list shows a particular set of splits, but the actual on-chain splits config e.g. only splits to the malicious actor.
• When receiving a lone metadata update event, we need to validate its content against the on-chain splits config. For the same reasons listed above; malicious actors could list splits in metadata that don't actually exist on-chain.

But what should we do if there's any anomaly? We can't just ignore events that appear invalid, because then the UI would just be in an outdated state, which is just as bad. I suggest that we add some kind of flag for now, called something like invalidState, which we flip to true if validations like those described above fail. If this flag is true, the app can either refuse to display the affected entity entirely (with an explanation), or display a large warning that information below may be inaccurate. That way, we greatly reduce the likelihood of successful manipulation attempts, while not needing to build complicated logic for handling unexpected data in events. If the flag is wrongly flipped because of some kind of bug within the event processor, we can just fix the bug, recreate the DB, and all is fine.