annotate virtual/durable vrefs

[warner]

fix: add 'v'/'d' virtual/durable annotations to vrefs

This changes the vref format to reveal the ephemeral/virtual/durable
status of each object to the kernel. The kernel doesn't normally care,
but I'd like to move upgrade-time responsibility for abandoning
merely-virtual objects from the vat to the kernel, which requires the
kernel be capable of distinguishing them from durable objects.

In this format, ephemeral objects exports are o+NN, merely-virtual
object exports start with o+vNN (where NN names the KindID, and
the vref always has an instance-ID suffix, so like o+v34/2), and
durable object exports use o+dNN. As before, virtual/durable vrefs
might include an additional facet-ID suffix: o+v34/2:1.

Since the kernel doesn't yet care about details of the vref, very
little code changed in packages/SwingSet: just a few tests that had
stronger opinions about vrefs than they should be having. The kernel's
copy of parseVatSlots grew the ability to distinguish virtual from
durable, but nothing uses it yet.

closes #6695

[warner]

cc@mhofman @dckc because we might have some other tools (slogfile visualizer? OTEL telemetry conversion?) that are sensitive to the format of vrefs. Note that krefs remain unchanged.

[mhofman]

move upgrade-time responsibility for abandoning merely-virtual objects from the vat to the kernel

In the CDP world, I'd imagine this responsibility would be on the CDP, with the kernel un-aware of the differences, right? I see virtualized / durable objects as an internal CDP concern, like the vatstore is.

some other tools (slogfile visualizer? OTEL telemetry conversion?) that are sensitive to the format of vrefs

I don't believe any of these tools are sensitive to the format of the vref (in the otel case I think we only care about kref anyway)

[mhofman]

LGTM

The duplication of code/changes between Swingset and swingset-liveslots is a bit unfortunate.

[mhofman]

Out of curiosity, is there a reason you didn't go with virtual including durable instead of making them mutually exclusive ?

[warner]

I thought about that, but the documentation I came up with was too confusing, which tells me that the API would have been too confusing. If "virtual" means "virtual (and maybe also durable)", then "durable" means "virtual and durable", and that's not going to be an obvious split if you're just reading some code. Figured that explicit is better than implicit.

[warner]

The duplication of code/changes between Swingset and swingset-liveslots is a bit unfortunate

Yeah, when I split swingset-liveslots/ out to a separate package, I thought about making a third package to hold the common support code. But 1: I don't yet know how that support code will need to be refactored, there might be other combinations of dependencies that I haven't discovered yet, needing more common packages, and 2: it makes some claims about independent updatability that aren't necessarily supported. This parseVatSlots() change is a good example: we're really defining an interface between vats and the kernel: changing the contents of the common support code doesn't cause existing vats to start behaving differently. We might augment the interface and have a kernel that supports two separate flavors of this interface, but the old version of liveslots needs to keep using the old parseVatSlots.

I figure that once the dust settles, I'll look around and see what code can be safely/usefully factored back out into shared packages.

[FUDCo]

In the CDP world, I'd imagine this responsibility would be on the CDP, with the kernel un-aware of the differences, right? I see virtualized / durable objects as an internal CDP concern, like the vatstore is

What is "CDP"?

[mhofman]

In the CDP world, I'd imagine this responsibility would be on the CDP, with the kernel un-aware of the differences, right? I see virtualized / durable objects as an internal CDP concern, like the vatstore is

What is "CDP"?

I borrowed the name from @warner's parallelization scheme: #6447

[FUDCo]

Looks straightforward. My only concern is the proliferation of boolean tests all over the place getting more complicated -- that's not an objection to this set of changes per se, but more flagging a nascent concern about creeping complexity.