Ck duplicate interest

[suraviregmi]

Summary of Behavior Change

This PR removes the old probe-segmentation pattern in both consume() and decryptContent(), prevents multiple CK fetches for shared CKs, and ensures that MustBeFresh is set correctly where required.

What the OLD logic did

Data fetch path

• Expressed one Interest.
• Checked the first returned Data to see if it had a segment component.
• If segmented, started a second SegmentFetcher for the same name.
• This caused:
  • Double fetch for segmented data.
  • Extra RTT spent only to detect segmentation.
  • Two different code paths depending on the first Data result.

CK fetch path

• CKs were fetched multiple times when multiple data packets referenced the same CK.

Updates in the PR

Unified segmentation handling

• The first Data packet determines whether segmentation exists.
• If segmented, use a single SegmentFetcher to retrieve the full object.
• If not segmented, validate and continue immediately.
• No dedicated probe Interest.

CK fetch is now single-shot

• CKs are fetched once per name, even when reused.
• Prevents repeated CK fetches interest in high-volume pipelines.

Eliminates redundant fetches

• Segmented objects are fetched once.
• No duplicate Interests.
• No duplicated callbacks.