Redesign database for secagg to add LOM secagg context

[srcansiz]

Secure aggregation contexts are save in the database respecting certain formats respecting the type of context:

//Biprime
{
 'secagg_id': xxxx,
 'secagg_version': xxx,
 'parties': <list of participating parties>,
 'type': <enum BiprimeType.DYNAMIC.value, BiprimeType.DEFAULT.value>,
 'context': Dict[str, int]
}

// Servkey 
{
 'secagg_id': xxxx,
 'secagg_version': xxx,
 'parties': <list of participating parties>,
 'context': Dict[str, int],
 'experiment_id': xxxx,
}

In Tinydb there are different tables for Servkey and Biprime.

This issue focuses on how database should be redesign after adding LOM context. LOM context is different that other context since it consist of key-pairs between a node and other nodes. For example,

This is an example secagg context that is going to be saved in node-1 database in a FL experiment. There are node-2 and node-3 in the experiment:

<key-pair-node-1-node-2>, key-pair-node-1-node-3

During the encryption phase, - and + signs are assigned to these individual keys to sum or subtract from an integer depending on the id of the node that is paired. Therefore, it is important to know the identity of the node that the key is paired. Respecting this information please provide:

• How context property of db entry should be design: Dict, List, Set etc.
• a.1- Should we use single table to keep all types of secagg context or keep using different tables for different context types.
• a.2 - depending on a.1 please propose a final database entry design + create an additional issue if needed (*)

(*) if a.1 decides to merge the existing secagg tables, then an additional issue needs to be created for updating SecaggServkeyManager and SecaggBiprimeManager:

• extend with another field type (servkey, biprime, lom) to be able to easily associate a secagg entry to its type
• rewrite the methods from SecaggServkeyManager and SecaggBiprimeManager (eg for "remove" a SecaggServkeyManager.remove() should never be able to remove a biprime key, even if we provide the correct secagg_id)

[ybouilla]

For JL aggregation, I propose as a dataset design:

Dear everyone! This is a first proposal for database redesign

{

'secagg_scheme': x, 

'context':    {
             0: { //Biprime
               'secagg_id': xxxx,
               'secagg_version': xxx,
               'parties': <list of participating parties>,
               'context': Dict[str, int],
               'experiment_id': xxxx,
              },
              1: {  //ServerKey
             'secagg_id': xxxx,
             'secagg_version': xxx,
             'parties': <list of participating parties>,
             'type': <enum BiprimeType.DYNAMIC.value, BiprimeType.DEFAULT.value>,
             'context': Dict[str, int]
            }, 
       }
}

Where 0 and 1 are SecaggElementTypes. The issue with this database model is that it is not easy to convert to a relational database