Reduce cost of oracles supplying prices (continuing invitations)

[Chris-Hibbert]

What is the Problem Being Solved?

Currently Oracle operators supply prices to the flux aggregator using the [Continuing Invitation Pattern])https://docs.agoric.com/glossary/#continuing-invitation-pattern). This requires an extra round trip via the smartWallet and Zoe before the Oracle can deliver a price update.

Description of the Design

#8733 describes an approach to invoking a method directly on an object received in an offer result. If that existed, we could redesign the way Oracles deliver prices to the chain. This simplification might require a factor of 5 less work on the part of the chain. #8550 talks about how the smartWallet might distinguish invocable objects from those carrying invitations.

Security Considerations

CAPTP would continue to ensure that only the appropriate party would be able to send the message. The smartWallet is already managing state and holding on to object references.

Scaling Considerations

Oracles providing prices is currently a significant part of the load on our chain. We'd like to add more assets, and more services. Reducing the load required would help significantly.

Test Plan

TBD

Upgrade Considerations

This requires a change to the SmartWallet before the fluxAggregator can provide a new API, which would have to be adopted by the Oracle middleware.