Provide /custom/vstorage/flatdata endpoint for contract notification data

[gibson042]

What is the Problem Being Solved?

Telemetry is currently emitted by sending an object to a notifier-package publisher/publication/updater that is coupled to a chainStorage node, with the result that what gets written into chain storage is capdata like

{
  "slots": ["board0425", "board03125", "board03523"],
  "body": "{\"centralAmount\":{\"brand\":{\"@qclass\":\"slot\",\"iface\":\"Alleged: RUN brand\",\"index\":0},\"value\":{\"@qclass\":\"bigint\",\"digits\":\"1859152806\"}},\"liquidityTokens\":{\"brand\":{\"@qclass\":\"slot\",\"iface\":\"Alleged: BLDPoolLiquidity brand\",\"index\":1},\"value\":{\"@qclass\":\"bigint\",\"digits\":\"4455322155\"}},\"secondaryAmount\":{\"brand\":{\"@qclass\":\"slot\",\"iface\":\"Alleged: BLD brand\",\"index\":2},\"value\":{\"@qclass\":\"bigint\",\"digits\":\"2159517880\"}}}"
}

This is good for capdata-aware consumers, but cumbersome for more generic clients. get-flattened-publication.sh mitigates it somewhat, but that script itself becomes another dependency and still produces rather verbose output.

We wish instead for flattened (tabular) data to be available directly.

Description of the Design

Provide a new RPC endpoint at e.g. /custom/vstorage/flatdata which uses the same underlying store capdata and applies a straightforward translation similar to get-flattened-publication.sh, resulting in something like:

{
  "centralAmount-brand-id": "board0425",
  "centralAmount-brand-allegedName": "RUN",
  "centralAmount-value": "1859152806",
  "liquidityTokens-brand-id": "board03125",
  "liquidityTokens-brand-allegedName": "BLDPoolLiquidity",
  "liquidityTokens-value": "4455322155",
  "secondaryAmount-brand-id": "board03523",
  "secondaryAmount-brand-allegedName": "BLD",
  "secondaryAmount-value": "2159517880"
}

Rejected/deferred possibility

Producers can be updated to emit a simpler representation of their telemetry, in addition to the reliable objects. It can still be JSON, but should be flat (in the sense that every member of the top-level object has a JSON-primitive value—no objects, arrays, bigints, non-finite numbers, undefined, etc.). For example, the above could be simplified to

{
  "centralAmountBrandId": "board0425",
  "centralAmountBrandAllegedName": "RUN",
  "centralAmountValue": "1859152806",
  "liquidityTokensBrandId": "board03125",
  "liquidityTokensBrandAllegedName": "BLDPoolLiquidity",
  "liquidityTokensValue": "4455322155",
  "secondaryAmountBrandId": "board03523",
  "secondaryAmountBrandAllegedName": "BLD",
  "secondaryAmountValue": "2159517880"
}

Doing this would require

1. Establishing and documenting conventions for
   • the pattern of chain storage paths for such simplified data (e.g., a suffix like ".flat" such that capdata is written at published.amm.pool0 and the corresponding simplified data is written at published.amm.pool0.flat), and
   • the formatting of such a structure (e.g., words in field names combined as camelCase, brands identified by a pair of <label>BrandId and <label>AllegedName fields, and bigints represented as a string containing only decimal digits).
2. Updating contracts and/or vats to emit telemetry in the new format according to those conventions.

Security Considerations

It is probably important that "alleged" or similar remain in the name of any field identifying a brand name, to avoid supporting unjustified trust on the part of a consumer. We may also need to consider the extent to which the Agoric board is privileged in identifying a brand.

Test Plan

No special considerations.

[Tartuffo]

@gibson042 Can you please change the description of this ticket to reflect what we discussed today?

[Tartuffo]

@gibson042 I made some changes to the title and description, please refine as appropriate!