Change Details

In case the delegation is empty, the avahello signature needs to be generated with the proof master key directly. This adds the proof master key to the avahello network message, to ensure that we can immediately verify that signature when receiving an AVAHELLO message, even if we don't already have the proof. This change also removes the responsibility for `Delegation::verify` to check that the proofid matches a given proof. Now it only checks the delegation itself, and the proofid verification becomes the responsibility of `PeerManager::addNode`. The delegation verification no longers needs to be done in `PeerManager::addNode`, as the node is banned if the delegation verification fails on avahello reception. A side effect of these changes is that the `DelegationResult::INCORRECT_PROOF` is no longer needed. Now a delegation can only be bad due to a bad signature.

The proof master key is needed to check the delegation and the signature included in the `AvaHello` message. The `LimitedProofId` is required to check that the provided proof master key actually belongs to the advertised proof, by allowing to compute the proofid using the limited id and master key, and then comparing the computed id to the one included in the delegation. The delegation verification no longers needs to be done in `PeerManager::addNode`, as the node is banned if the delegation verification fails on avahello reception.

In case the delegation is empty, the avahello signature needs to be generated with the proof master key directly. This adds the proof master key to the avahello network message, to ensure that we can immediately verify that signature when receiving an AVAHELLO message,The proof master key is needed to check the delegation and the signature included in the `AvaHello` message. even if we don't already have the proof. This change also removes the responsibility for `Delegation::verify` to check that the proofid matches a given proof.The `LimitedProofId` is required to check that the provided proof master key actually belongs to the advertised proof, Now it only checksby allowing to compute the proofid using the delegation itselflimited id and master key, and the proofid verification becomesn comparing the computed id to the responsibility of `PeerManager::addNode`one included in the delegation. The delegation verification no longers needs to be done in `PeerManager::addNode`, as the node is banned if the delegation verification fails on avahello reception. A side effect of these changes is that the `DelegationResult::INCORRECT_PROOF` is no longer needed. Now a delegation can only be bad due to a bad signature.