Feat: Support ahead of time input-added event

[brunomenezes]

📄 Context

For the rollups v0.9.0, An InputAdded event could be submitted to a DApp that has not been created yet, by the usual pipeline; i.e. through the CartesiDAppFactory contract. It is necessary to handle such cases, distinguish the DApp origin, and deal with the aggregations done in factories and dashboard levels.

✔️ Solution

Include a state to the DApp data structure to help distinguish it and also below a list of things to be handled;

• Add a new property to the DApp entity in the graphQL schema called status that is of type enum with the following values [CREATED_BY_FACTORY, CREATED_BY_INPUT_ADDED_EVT]
• DApp creation should now signal through the status property the origin.
• If the DApp does not exist when handling the InputAddedevent
  • A new DApp should be created with an input count of 1
  • It should set the status signalling that it was created via input-added,
  • factory property should be a placeholder, i.e. virtual_factory.
  • It should not increment the dashboard aggregations like, e.g. dappCount | inputCount
  • Otherwise, it follows the currently implemented behaviour.
• When handling an ApplicationCreated and the DApp already exist;
  • it should update the status signalling creation by the factory.
  • It should add the DApp's input count to the Factory and Dashboard input-count fields, respectively.
  • it should update the factory property to the factory address.

📈 Subtasks

• Add the new enum definition to the graphQL schema.
• Add a new required field to the DApp entity called status typed as the enum defined above.
• Increment the application-created events for v0.6 and v0.8 to include the status (these versions are not affected by the problem)
• Augment handler code for the application-created event for v0.9 covering the abovementioned situation.
• Augment handler code for the input-events from InputBox contract covering the abovementioned situation.
• Include unit tests.

🎯 Definition of Done

• InputAdded events to non-existing DApps do not cause the indexing to fail.

[brunomenezes]

I am implementing this in the same branch for issue #8

[tuler]

Why do you think we need the property indicating the source of creation? We could just let the fields that we don’t know how to fill blank and filled up later

[brunomenezes]

Why do you think we need the property indicating the source of creation? We could just let the fields that we don’t know how to fill blank and filled up later

The only field we don't know is the factory address; all the rest are set with default values. I'm unsure if you are talking about adding the status field, but my rationale is to work with explicit intent rather than the opaque null here and there.