Query node: Remove the need for bootstrapping values

Memberships

• defaultInviteCount (initial value: 5) - this value is used to populate Membership.inviteCount during member creation. Once updated in the runtime, the update is reflected in MembershipSystemSnapshot.defaultInviteCount. Alternative solution: Include the value in MembershipBought and MemberInvited events on the runtime side and remove MembershipSystemSnapshot entity.
• membershipPrice (initial value: 100) - only used in MembershipSystemSnapshot entity for consistency. Alternative solution: Remove MembershipSystemSnapshot entity, Pioneer should fetch the price directly from the chain api (api.query.members.membershipPrice)
• referralCut (initial value: 0) - only used in MembershipSystemSnapshot entity for consistency. Alternative solution: Remove MembershipSystemSnapshot entity, Pioneer should fetch the value directly from the chain api if needed (api.query.members.referralCut)
• invitedInitialBalance (initial value: 100) - only used in MembershipSystemSnapshot entity for consistency. Alternative solution: Remove MembershipSystemSnapshot entity, Pioneer should fetch the value directly from the chain api if needed (api.query.members.initialInvitationBalance)

Storage system

• blacklist (initial value: []) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.blacklist directly if needed.
• storageBucketsPerBagLimit (initial value: 0) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.storageBucketsPerBagLimit directly if needed.
• distributionBucketsPerBagLimit (initial value: 0) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.distributionBucketsPerBagLimit directly if needed.
• uploadingBlocked (initial value: false) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.uploadingBlocked directly if needed.
• dataObjectFeePerMb (initial value: 0) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.dataObjectPerMegabyteFee directly if needed.
• storageBucketMaxObjectsCountLimit (initial value: 0) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.voucherMaxObjectsNumberLimit directly if needed.
• storageBucketMaxObjectsSizeLimit (initial value: 0) - only used in StorageSystemParameters entity. Alternative solution: Remove StorageSystemParameters entity, apps should use api.query.storage.voucherMaxObjectsSizeLimit directly if needed.
• nextDataObjectId (initial value: 0) - used to connect created channel/video assets during ChannelCreated and VideoCreated events. Alternative solution: Don't initialize any value, 0 should just be assumed in case if missing. This should be no longer needed after https://github.com/Joystream/joystream/issues/3084

Working groups

• name - WorkingGroup entities are bootstrapped with a name that matches the api module name in order for the QN to be able to connect WorkingGroup entity to an event that is beeing processed.
• budget (initial value: 0) - each group can have an initial budget set in the runtime. Currently this is 0.

Alternative solution:
Change the schema so that there is no WorkingGroup entity, but a WorkingGroup enum instead. There is a map of working group module name to WorkingGroup enum variant. WorkingGroup has no properties of its own. The budget can be retrieved either by directly querying the chain (api.query[group].budget) or fetching the last BudgetSetEvent. The group metadata can be retrieved by fetching the last WorkingGroupMetadata. The leader can be fetched with a query like workers(where: group_eq: $group, isLead_eq: true }). All references to WorkingGroup entity should be changed to simple WorkingGroup enum values.

Council

For council mappings we're creating the initial election / stage / council entities mostly for the purpose of allowing to create relationships between subsequent stage updates, candidacies etc. and current election / council.

Alternative solution:

• Modify the mappings so that they don't need an initial empty council entity (make relationships to it optional where needed)
• Remove ElectionRound entity, replace references to it with ElectionRound number istead. Make election round (cycleId) part of AnnouncingPeriodStartedEvent and query the last such event to retrieve cycleId in the mappings (assume 0 in case there are no events yet)
• Remove the need for initial CouncilStageUpdate. The initial stage should be assumed to be Announcing by Pioneer and other apps. Candidate count can be retrieved with a query like candidatesConnection(where: { cycleId_eq: $currentCycleNumber }) { totalCount }, it doesn't need to be part of CouncilStageUpdate entity.

┆Issue is synchronized with this Asana task by Unito

Start by reviewing the Query node mappings and the named MembershipSystemSnapshot, StorageSystemParameters, WorkingGroup, election, council, and stage entities. Determine which alternative design is accepted, then trace the affected mappings and relationships; done means bootstrapping values are no longer required without breaking event processing or downstream queries.