Merge pkg/ocap into pkg/vat

[lthibault]

I think our package structure would be rendered more legible by merging pkg/vat and pkg/coap into a single package responsible for all aspects of networked object capabilities via Cap'n Proto.

Currently,

• pkg/vat exports the Network type, which provides an API for mapping object capabilities to libp2p streams; and,
• pkg/ocap contains object-capability implementations that can be registered to vat.Network.

These two functions seem intimately related, and I'm having trouble justifying the decision to split them into separate packages. Moreover, a single vat package would seem the natural place to host code for https://github.com/wetware/ww/issues/16 (ocap authentication), which I plan on addressing in the coming weeks.

@aratz-lasa Any thoughts or objections?

Proposal

My sense is that it would be most sensible to merge pkg/ocap into pkg/vat for the simple reason thatpkg/vat is imported by a greater number of packages. I also happen to be quite attached to the vat package identifier 😉. I propose the following package structure:

/pkg/vat
├── cap
│   ├── anchor/
│   ├── cluster/
│   └── .../
├── auth.go  // todo:  shall contain code for capability authentication
├── doc.go
├── capability.go
├── future.go  // formerly part of pkg/ocap
└── vat.go

The result is that generic capability-related exports are located in the vat package, in particular: vat.Future and its derivatives. Moreover, this allows us to eschew the ocap package identifier in favor of cap, which I personally prefer. (It was originally renamed to ocap to avoid clashing with the built-in function that returns slice capacity. This is no longer a problem, since we will no longer any types from the cap package).

Impact

This shouldn't affect wire compatibility, since we are not actually modifying any schemas or altering the mapping of vat.Network.

[aratz-lasa]

I think this is a very good refactoring of our package structure. Currently, it is not obvious that vat is used for exporting and connecting to capabilities. With this new structure users will immediately recognize that vat.Network is a key component for capabilities. Moreover, I really like the idea of getting rid of ocap.

So let's restructure it!