Checksum support in SPARK

[senier]

Cf. #240, #222

[treiher]

The current design (#222) allows to specify checksums which depend fields following a checksum field. This is required for example for ICMP messages, where all fields must be set before the checksum function could be called.

The generated SPARK code only allows to set fields in order of their occurrence. If any previously set field is changed, all subsequent fields would be invalidated. In case of ICMP this would mean that at first all fields of a ICMP would need to be set, before the checksum function can be used. If the result of the checksum function is used to set the checksum field, all subsequent field would be invalidated and must be set again.

Solutions

1. Removing the invalidation of subsequent fields by allowing fields to be set in "any" order (Lazy message parsing and generation #107)
2. Adding a function for setting a checksum field (based on the provided checksum function) which does not invalidate subsequent fields (this would require that the structure of a message does not depend on the value of the checksum field)

[senier]

I'd prefer the more generic solution of #107 in favor of a special case handling proposed in 2. Question is, how complicated is the implementation of #107 going to be?

[treiher]

The changes would be quite big. My optimistic estimate would be 5-8 person days just for the relevant parts of #107 with a high risk of finding unforeseen problems.

[senier]

Then we should go for option 2 and validate that the structure of the message really does not depend on the checksum field (which should normally be the case as the checksum is set to 0 and filled in later in most protocols).