Fix repair transmission flagging

[sleepybishop]

Hello,

This PR fixes an issue where re-transmitted data and metadata packets were not properly flagged as repairs.

What's included

• Restored the NormObjectMsg::FLAG_REPAIR assignment in normObject.cpp and updated pending_info transitions so that NORM_INFO and NORM_DATA messages properly track when they are reactive repairs.
• Updated NormBlock::TxUpdate() in normSegment.cpp to explicitly mark a block as IN_REPAIR whenever its repair state increases.
• A new test suite tests/normRepairFlagTest.cpp to validate block repair states and receiver synchronization policies against flagged messages.

Notes

• Properly flagging these messages is important for receiver-side logic, like sync policies, which rely on distinguishing between original data and repair packets.
• I'd be happy to adjust the tests or approach if there's a preferred way you'd like these repair states tracked in NORM.

If the fix looks ok, I think this should resolve TODO 0.

[sleepybishop]

Thanks for the review. Two things...

• The ci failure seems to happen because some things from protolib don't seem to be wired in cmake.
• Tangentially related to Add basic rateless codec support #102, in a rateless repair world, a third policy is useful in addition to SYNC_ALL and SYNC_CURRENT. For example a SYNC_REPAIR policy could accept repair symbols on current objects. Let me know if that would be a useful follow up.

[bebopagogo]

How would SYNC_REPAIR differ from SYNC_CURRENT .... basically be the same but be more permissive on allowing sync to parity packets and not just packets with user data content? That definitely makes sense for rateless and possibly even the existing FEC codecs when those symbols are not flagged as repair transmissions? I.e., we could just modify the SYNC_CURRENT policy to allow sync on non-flagged parity symbols ... since you added the code that makes that distinction more clear that may make sense versus an additional sync policy? The main intent of that was to limit late joining receivers impact on the session ... the other "rule" for sync current was to allow sync only during the first FEC block and, of course, with rateless that's a different sort of paradigm since generally it will be a single logical "block" ... just thinking out loud here if you have any specific use cases in mind.

[sleepybishop]

How would SYNC_REPAIR differ from SYNC_CURRENT .... basically be the same but be more permissive on allowing sync to parity packets and not just packets with user data content?

Precisely. I don't have a preference, but I had thought a third sync policy might prevent backwards incompatibilities, however this change in itself already did since prior to it was already behaving that way because the REPAIR_FLAG was missing, so I could see the case for just expanding SYNC_CURRENT.