Rearchitect the combined networks API to nest the constraints?

[krivit]

Currently, if layers are nested within networks and/or time points, the resulting network object ends up containing the lists of constituent networks (with edges stripped) in .subnetcache and the blocks are identified by vertex attributes. The top-level network ends up containing:

• All the vertex attributes of the constituent networks and their constituent networks in turn.
• Specifically for vertex attributes that are used to identify blocks, each vertex in fact has a vector, and if there are multiple combinings on the same attribute, the most recent merging's IDs is prepended to the vector.
• Globally unique vertex IDs that are then used by the .block_blacklist constraint in combination with network attributes indicating block combinations to be blacklisted.
• A series of blockdiag() constraints, e.g., blockdiag(".LayerID") + blockdiag(".NetworkID").

In a perfect world, we should be able to combine networks with different, possibly incompatible constraints, and have it just work (TM). In principle, this can be accomplished as follows:

1. Implement an operator constraint, e.g., BlockDiag(attr, constraints) where constraints is a list of constraint formulas with an element for each block.
   1. For each block, it will initialise a proposal on its constraints. The stored constituent networks can be used to initialise these subproposals.
   2. When sampling, it will select a block, then call its proposal function to generate a proposal.
   3. This will create some overhead, since those proposal functions will need Network data structures to keep track of things.
2. The combining function no longer needs to keep track of the whole stack of things, just the networks it's combining.
3. Rather than try to harmonise the proposals from constituent networks, the combining function can simply call BlockDiag(combining_attr, list(~subnet1_constraints, ~subnet2_constraints, ...)).

[krivit]

@mschalberger, @corneliusfritz, this might simplify ergm.sign substantially, since it would then be possible to "tag" the signed network with the appropriate constraint, then when they are pooled as in a sample or a time series, the constraint would only "see" the actual signed network.

[krivit]

On the other hand, what if the proposal requests auxiliaries? It's important that the auxiliaries be evaluated on its subnetwork, but a proposal only requests auxiliaries at the top level.

[krivit]

OK, I believe I have something that works.