`RawPacket::setRawData` inherits previous buffer ownership semantics.

[Dimi1010]

Bug description

Describe the bug
Currently the ownership semantics of a RawPacket object are defined during construction via deleteRawDataAtDestructor parameter.

The issue is that RawPacket::setRawData allows specifying a new buffer, but does not take a new deleteRawDataAtDestructor. This makes the new buffer inherit the ownership of the old one. This is further compounded by the internal buffer ownership state being opaque to the user.

Code example to reproduce

using namespace pcpp;

timespec captureTime{};
LinkLayerType linkLayer = LINKTYPE_ETHERNET;

uint8_t* dataPtr = new uint8_t[100];
RawPacket rawPack(dataPtr, 100, captureTime, true /* take ownership */, linkLayer);

// No option to set the new raw data to be non-owning.
uint8_t stackAlloc[100];
rawPack.setRawData(stackAlloc, 100, captureTime, linkLayer, 55 /* frame length */);

rawPack.clear();  // Crash! This will cause a call to delete on stack memory.

Expected behavior
Add a parameter deleteRawDataAtDestructor to setRawData that updates the ownership for the new buffer.

---

PS: deleteRawDataAtDestructor parameter should really be renamed to something more concise like takeOwnership or something?

PS2: Why does the setRawData allow custom frameLength but constructor doesn't?

PcapPlusPlus versions tested on

PcapPlusPlus master branch

Other PcapPlusPlus version (if applicable)

No response

Operating systems tested on

Windows

Other operation systems (if applicable)

No response

Compiler version

MSVC

Packet capture backend (if applicable)

No response

[Dimi1010]

Fixed in #2036