feat: support slice view data on writing IPC

[ariesdevil]

Which issue does this PR close?

Part of #5506.

Rationale for this change

Support slice view data on writing IPC.

What changes are included in this PR?

Support slice view data on writing IPC.

Are there any user-facing changes?

No.

[tustvold]

I believe the intention of this code is to avoid writing out data buffers that aren't referenced by any views, perhaps as a result of slicing. I think this is probably better handled as a more general "compact" operation, that also handles pruning the data buffers themselves. I believe this is tracked by #5513

I'm not sure whether the IPC writer should be doing anything smart here?

Perhaps @alamb has thoughts on this

[ariesdevil]

Maybe we can just slice views here and hand over the data buffer to gc for processing. cc @alamb

[alamb]

I believe the intention of this code is to avoid writing out data buffers that aren't referenced by any views, perhaps as a result of slicing.

That is my interpretation too -- @ariesdevil can you confirm?

I think this is probably better handled as a more general "compact" operation, that also handles pruning the data buffers themselves. I believe this is tracked by #5513

Yes, that is my suggestion. The rationale for a separate gc operation is:

1. Since it is potentially expensive I think the user should decide when to do the check, rather than on each IPC call. I think some applications might have different tradeoffs between compacting / pruning and saving IPC space.
2. gc is more generally useful for operations other than IPC (consolidating memory down after a filter, for example)

Having a variation of gc that simply prunes unreferenced buffers (but not copy) might also be interesting

[ariesdevil]

Make sense, thanks @alamb @tustvold