Embed Robustness into mixnet.py

[youngjoon-lee]

We have discussed lots of time about the robustness layer, regarding its role and its name: #57 (comment). Now, I think it is time for us to make a conclusion about this.

Through many discussions, I end up with thinking that we don't need to define the Robustness class in this executable spec explicitly.

As I understand, the robustness layer has been suggested to clearly separate config reconstruction logic from the core mixnet logic. I totally agree with it. However, having an explicit Robustness component has made confusions. Some wondered whether it performs or will perform a role for components other than mixnet, and if so, what that role is. Also, if it's only for mixnet (at least in v1), others wondered why we shouldn't define the config reconstruction logic within the area of mixnet.

I also agree with these confusions. This topic might be an implementation detail that doesn't need to be discussed in the spec level.
So, in this PR, I'm suggesting a simpler structure. Config reconstruction is done in mixnet.py that is the top-most class of mixnet and has APIs for interactions with upper components. The actual mix/networking logic is defined in mixclient.py and mixnode.py.
I believe this structure is quite clear and will not cause further confusions.

Please provide your opinion here.
I'd recommend you to focus on the structure for now. There are some code that needs to be refactored, but I tried to minimize diffs to show the structure clearly. I'm gonna refine code after we made a conclusion.

[danielSanchezQ]

IMO this is simpler and better.

[zeegomo]

Haven't looked in detail at the code but it looks ok at first sight and I 100% agree with the premises

[alvatar]

I see that the code uses the naming "config", while we are discussing the concept of robustness. As mentioned in Notion, I think robustness is not a very accurate naming for what this does, so I think the code is in better place now.

[madxor]

Looks good to me.

Regarding the robustness layer, the initial idea was to extract configuration and management of the mixnet out of the mixnet layer. So maybe the "mixnet management layer/module/subsystem" name would suit it better or at least be less confusing. I was envisioning that in the farther perspective the "mixnet management layer/module/subsystem" would be responsible for learning how to set the mixnet based on the data coming from the consensus/network/coordination layers. Hence, having a separate layer in the future might be more beneficial but I see that it's not necessary at the moment.