Investigate propagating changes as they are made

[mjhouse]

Is your feature request related to a problem? Please describe. Currently, sections can be changed in ways that will break the binary. For example, if a new string is inserted into the section header string table (.shstrtable), then offsets for section names that reference later strings will be invalid.

Describe the solution you'd like There should be a minimum of boilerplate necessary to apply updates that are necessary due to changes in sections, symbols etc. (one function call to apply changes, ideally), and the updates themselves should be discrete and minimal- no massive for-loops with hard-coded checks. Complicating this, I'd also like to avoid every component, symbol, and section carrying around a boxed mutable reference to the binary.

Currently, I'm thinking-

• There will be a globally unique ChangeId that maintains the order of changes, regardless of what component they're in.
• Each component will generate Change objects when they are modified, which contain flags and before/after values.
• When the user calls an .apply() method on the binary, the binary will-
  • Iterate through all components and capture Change objects
  • Sort the changes by ChangeId
  • Iterate through all components and apply the changes.

I'm not sure where the logic to apply the changes should live- in the previous example, we insert a string into the section header string table, which generates a Change object, which is captured by the binary, then passed to all components to apply. Should the components all have a method to accept change objects? Should "ChangeAppliers" be defined that accept both a component and a change object? Should the binary handle this?

There are going to be hundreds of changes that will be applied to different components, it makes sense that they should be outside of the sections/symbols etc.

[mjhouse]

Resolved by #40.

In the final design, the update queue stores a collection of lambdas that target a particular struct like Section or FileHeader. Binary updates by calling update on each section, sections update section headers etc. Probably need to also update Table/TableMut references.