refs: Agoric#9281

## Description
AsyncFlow requires that everything passing the membrane is durable. This makes the facade objects durable to conform.

Doing so for `localChainFacade` is deferred so we can get this into master sooner, to aid @erights 's Agoric#9521 .

### Security Considerations
none
### Scaling Considerations

Exo for each chain and each account

### Documentation Considerations
none
### Testing Considerations

Existing coverage

### Upgrade Considerations
none, not yet deployed

refs: Agoric#9281

## Description

AsyncFlow requires that everything passing the membrane is durable. This makes the facade objects durable to conform.

Following Agoric#9529 

### Security Considerations
none

### Scaling Considerations
Exo for each chain and each account


### Documentation Considerations
none

### Testing Considerations
Existing coverage


### Upgrade Considerations
not yet deployed

Vat termination now makes the kernel do a console.log like:

 `kernel terminating vat v6 (failure=true)`

Vat upgrade now announces the start of the upgrade process with:

 `attempting to upgrade vat v6 from incarnation 0 to source b1-..`

in addition to announcing the success or failure of the upgrade

 `vat v6 upgraded from incarnation 0 to 1 with source b1-..`
 or
 `WARNING: vat v6 failed to upgrade from incarnation 0 (startVat)`

- refs: Agoric#9449

- refs: Agoric#9449

- refs: Agoric#9449

refs: Agoric#9449 

## Description

- [x] convert icqConnectionKit to return vows
- [x] convert Orchestration service (`service.js`) to return vows 
- [x] convert chainAccountKit to return vows

### Security Considerations


### Scaling Considerations

These changes are necessary towards supporting using `orchestration` in `asyncFlow`. 


### Documentation Considerations


### Testing Considerations


### Upgrade Considerations

refs: Agoric#9281 

## Description

AsyncFlow requires that everything passing the membrane is durable. This makes the ChainHub durable by making it an Exo.


### Security Considerations
none

### Scaling Considerations

It's a singleton, because there will only be one per vat.

### Documentation Considerations
none

### Testing Considerations
Existing coverage

### Upgrade Considerations
Not yet deployed.

Now that it's an Exo, we have to consider its state an upgradability. We expect to make a new one on each vat invocation. The only state it has is cache of AgoricNames and data supplied by the contract.

closes: #XXXX
refs: Agoric#9531 (comment)

## Description

The implementation of `setTestJig` at https://github.com/Agoric/agoric-sdk/blob/37ec151b08de3d8e432a2599ccc532d4e72caedb/packages/zoe/src/contractFacet/zcfZygote.js#L358 treats its param as optional. The call to `setTestJig` at https://github.com/Agoric/documentation/blob/89a7dd53cd59b4008a36d23abdfa5665d1852336/snippets/tools/zcfTesterContract.js#L12 omits its parameter. The doc-comment on the type at https://github.com/Agoric/agoric-sdk/blob/37ec151b08de3d8e432a2599ccc532d4e72caedb/packages/zoe/src/contractFacet/types-ambient.d.ts#L139 explains the parameter as optional. But the type itself declares the parameter as mandatory.

This initially led me at Agoric#9531 to declare the parameter as mandatory in the new `ZcfI` interface guard, but that caused the failure in the documentation repo discussed at https://github.com/Agoric/agoric-sdk/blob/37ec151b08de3d8e432a2599ccc532d4e72caedb/packages/zoe/src/contractFacet/types-ambient.d.ts#L139 . My comment in the code there and the subsequent discussion assumes that the usage at the documentation repo is what needs to be fixed. But given this other evidence, I think the static type needs to be fixed to type that parameter as optional. Agoric#9531 would then be ok as is, only needing removal of the comment indicating something is amiss.

### Security Considerations
There is an existing security concern with the existence of `setTestJig` at all. But this PR does not affect that security concern at all.

### Scaling Considerations
none
### Documentation Considerations
This PR would make the `setTestJig` call currently in the documentation repo correct.
### Testing Considerations
This problem was initially detected when testing Agoric#9531 when the guard declared the parameter as mandatory. This does reenforce the lesson that TS types are unsound by enforced guards are sound.
### Upgrade Considerations
This PR is only a static change consistent with all current usage and implementation, and so should have no upgrade considerations. However, just to minimize risk, it still makes sense to hold this back till after master is snapshot for u16.

Staged on Agoric#9533 

refs: Agoric#9281 

## Description

The `zcf` object will effectively need to be passed through `orchestrate` as an endowment. Because zcf is not durable, or even an exo, we were originally planning to do it with a mechanism involving a standing durable object, and then wrap and unwrap it on either side of the membrane. But if `zcf` were durable, we wouldn't need all this complexity. It turns out, if this PR is correct, that making `zcf` durable is trivial.

### Security Considerations

Making `zcf` into a durable exo also involves giving it an interface guard. The interface guard in the first commit of this PR makes a needed exception for `makeInvitation` and `setTestJig` because both of them accept non-passable parameters. The `defaultGuards: 'passable'` option means that all other methods default to a guard that merely enforces that all arguments and return results are passable. This does make `zcf` somewhat more defensive, but not much.

Given this starting point, we can grow that `ZcfI` interface guard to do more explicit input validation of the other methods, which will help security, and make us less vulnerable to insufficient input validation in the zcf methods themselves. As we move more of the input validation to the method guards, we should be able to remove ad hoc input validation code in the method which has become redundant. Replacement of ad hoc input validation with declarative guard-based input validation should help security.

I don't yet know whether I'll grow the `ZcfI` interface guard to have these explicit method guards in further commits to this PR or in later PR.

### Scaling Considerations
The extra guard checks are potentially an issue, but we won't know until we profile.

### Documentation Considerations
none

### Testing Considerations

I need to understand `setTestJig` better.

### Upgrade Considerations

Making `zcf` durable means that it has a durable identity that survives upgrade. As a durable exo singleton, it is stateless, meaning that it gets back all the state it needs during `prepareExo` as state that its methods capture (close over) rather than as exo instance state. This reflects naturally the initial intuition that the `zcf` endowment, being stateless, could just be represented to `asyncFlow` as a singleton standin, re-endowed during the prepare phase.

- returning unwrapped vows to ensure tests are passing and functionality is preserved

refs: Agoric#9449

## Description

Returns unwrapped vows in `Orchestrator` (`makeLocalAccount`, `getChain`).

https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-rc/

refs: Agoric#9152 

## Description

Typescript 5.5: https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-rc/

(an earlier push also had Agoric#9479 but I moved the commits out)

### Security Considerations

n/a, linting

### Scaling Considerations

n/a, linting


### Documentation Considerations

none

### Testing Considerations

none

### Upgrade Considerations

n/a, linting

refs: Agoric#9449

## Description
A lint rule to help identify code that doesn't conform to the membrane passing requirements in Agoric#9449. 

Once we've brought all the modules into conformance this should be upgraded from a warning to an error.

### Security Considerations
none

### Scaling Considerations
none

### Documentation Considerations
none

### Testing Considerations
CI

### Upgrade Considerations
none

out of exo module

refs: Agoric#9449 

## Description

Make ChainHub exo resumable, returning vows and never promises.

Reviewers, this should confirm to the criteria in 9449,
- no async functions
- no callWhen guards
- methods that don't return immediately return Vows
- methods that return vows don't throw

This also makes the orchestration facade able to receive vows but still return promises.

### Security Considerations
none

### Scaling Considerations
none

### Documentation Considerations
none

### Testing Considerations
Existing coverage

### Upgrade Considerations
Not yet deployed. Vows improve upgrade robustness

refs: Agoric#8461 

## Description
Rely on corepack for yarn version.

Bump the yarn version to latest.

### Security Considerations
none
### Scaling Considerations
none

### Documentation Considerations

I think our docs already say to start with `corepack enable`. Not certain.

### Testing Considerations
- [x] run locally

Fails if corepack not yet enabled. It should be, so if this change causes errors that would help us to detect. Corepack is important in order to upgrade to Yarn 4 eventually.

### Upgrade Considerations
none

closes: Agoric#9325


## Description

Auto-retry the flaky test.

### Security Considerations
none

### Scaling Considerations
none

### Documentation Considerations
none

### Testing Considerations
The problem it's fixing is intermittent. If it passes CI once, let's let it in and see over the following days whether CI failure is down. (And reopen the issue that landing this closes)

### Upgrade Considerations
none

refs: Agoric#9449

## Description
More exos returning vows. Note these are _heap_ vows due to https://github.com/Agoric/agoric-sdk/blob/944adea10660e68a65c10a2b32b6899919315e31/packages/vow/vat.js#L29-L31

### Security Considerations
none

### Scaling Considerations
none

### Documentation Considerations
none

### Testing Considerations
CI

### Upgrade Considerations
none

refs: Agoric#8896

## Description

Extracted from Agoric#9534 to focus that PR on multichain and lighten the review. Also it had merge conflicts with master that this resolves.

### Security Considerations
nothing new

### Scaling Considerations
no

### Documentation Considerations
none

### Testing Considerations
new coverage

### Upgrade Considerations
none

# This is the 1st commit message:

create dedicated files for test assertions and tools

# This is the commit message #2:

Add new test file for liquidation visibility

# This is the commit message #3:

auctioneer snapshot

# This is the commit message #4:

Update visibility tests and helper functions

# This is the commit message #5:

add tools and assertions to match subscriber with vstorage data

# This is the commit message #6:

update test visibility of vault liquidation

# This is the commit message #7:

fix(liquidationVisibility): fix linting errors

# This is the commit message #8:

fix(liquidationVisibility): type error

# This is the commit message #9:

chore(liquidationVisibility): #4 testing tools setup

# This is the commit message #10:

chore(liquidationVisibility): #4 improve testing tools

# This is the commit message #11:

chore(liquidationVisibility): #4 improve testing tools

# This is the commit message #12:

fix(liquidationVisibility): linting fixes

# This is the commit message #13:

chore(liquidationVisibility): fix test names

# This is the commit message #14:

fix(liquidationVisibility): lint fix

# This is the commit message #15:

chore(liquidationVisibility): #4 implement `assertNodeInStorage`

# This is the commit message #16:

fix(liquidationVisibility): #4 lint fix

# This is the commit message #17:

chore(liquidationVisibility): #4 test skeleton is ready

# This is the commit message #18:

chore(liquidationVisibility): #4 add marshaller for comparing data from the vstorage

# This is the commit message #19:

chore(liquidationVisibility): sample test for `preAuction` and `postAuction` data fields

# This is the commit message #20:

chore(liquidationVisibility): make sure `assertStorageData` works

# This is the commit message #21:

chore(liquidationVisibility): #4 add test for case 2b, uncomment assertions for running the tests

# This is the commit message #22:

feat(liquidationVisibility): create liquidation storageNodes and recorderKits

BREAKING CHANGE: Introduced the `_timestamp` as an argument for the vaultManager liquidateVaults method.

feat(liquidationVisibility): write preAuctionState and auctionResultState to Vstorage

BREAKING CHANGE: a getVaultId method was included in the Vault interface, which returns the vault `idInManager`

fix(liquidationVisibility): fix type definitions errors and concurrently await multiple promises

feat(liquidationVisibility): write postAuctionState to Vstorage

BREAKING CHANGE: the getVaultId method of vaults interface was updated to getVaultState, which will return the vault phase as well

chore(liquidationVisibility): update helper methods, type definitions and names

fix(liquidationVisibility): lint fix

fix(liquidationVisibility): update sequence to write auction state to Vstorage and its structure

The helper methods built for this purpose became unnecessary and were removed.

fix(liquidationVisibility): update postAuctionState structure and change to writeFinal recorder method

fix(liquidationVisibility): remove temporary changes made to tests

fix(liquidationVisibility): #4 test for scenario 2b passed, test api updated, #7 is fixed

chore(liquidationVisibility): #4 test for scenario 2a passed

chore(liquidationVisibility): #4 update scenario 1

Squashed commit of the following:

commit 728d695
Author: anilhelvaci <anilhelvaci96@gmail.com>
Date:   Wed Jan 31 14:28:14 2024 +0300

    chore(liquidationVisibility): uncomment post auction assertion in `liq-result-scenario-1`

commit dd3fbdb
Author: anilhelvaci <anilhelvaci96@gmail.com>
Date:   Wed Jan 31 14:25:22 2024 +0300

    fix(liquidationVisibility): lint fix

commit 6920d1a
Author: anilhelvaci <anilhelvaci96@gmail.com>
Date:   Wed Jan 31 14:22:28 2024 +0300

    fix(liquidationVisibility): explain Promise.allSettled

commit 732e1d7
Author: anilhelvaci <anilhelvaci96@gmail.com>
Date:   Wed Jan 31 11:37:45 2024 +0300

    feat(liquidationVisibility): handle errors that might arise from other vats

commit 683f56d
Author: anilhelvaci <anilhelvaci96@gmail.com>
Date:   Tue Jan 30 14:31:13 2024 +0300

    feat(liquidationVisibility): add LiquidationVisibilityWriters to improve readability, fetch schedule during the auction itself

commit 4c45f2a
Author: anilhelvaci <anilhelvaci96@gmail.com>
Date:   Tue Jan 30 10:30:02 2024 +0300

    fix(liquidationVisibility): add pattern matcher to `getVaultState`

chore(liquidationVisibility): #4 add auctioneer wrapper and update setupBasics

chore(liquidationVisibility): #4 add mock makeChainStorageNode

chore(liquidationVisibility): #4 add tests for no vaults and rejected schedule

fix(liquidationVisibility): #4 add setBlockMakeChildNode method and update file name

fix(liquidationVisibility): #4 update import path

chore(liquidationVisibility): #4 add liq-rejected-timestampStorageNode test

fix(liquidationVisibility): #4 fix bug with at makeChildNode

fix(liquidationVisibility): #4 update test names and comments

fix(liquidationVisibility): #4 lint fix

chore(internal): create key-value pairs for Promise.allSettled values

fix(internal): make allValuesSettled a mapper for resolved promises and silently handles rejected ones

fix(internal): fix doc

fix(liquidationVisibility): make sure promises are assigned in key-value fashion, lint fixes.

chore(liquidationVisibility): extend liq-rejected-timestampStorageNode and clean outdated comments

fix(liquidationVisibility): revert update made to package.json

chore(liquidationVisibility): update snapshot generated by unit tests

fix(liquidationVisibility): lint fix

chore(liquidationVisibility) #4 test multiple vaultManagers

fix(liquidationVisibility): #4 lint fix

fix(liquidationVisibility): add pattern matcher to `getVaultState`

feat(liquidationVisibility): add LiquidationVisibilityWriters to improve readability, fetch schedule during the auction itself

chore(liquidationVisibility): init work for bootstrap tests

chore(liquidationVisibility): created test-liquidation-visibility.ts and started building a test suite

chore(liquidationVisibility): upgrade tests are implemented.

Refs: #15

fix(liquidationVisibility): vaults are now displayed in the correct order at `vaults.preAuction`

Refs: #13

fix(liquidationVisibility): vault phases are now displayed correctly at `vaults.postAuction`

Refs: #14

chore(liquidationVisibility): add storage snapshot

Refs: #15

fix(liquidationVisibility): don't reverse `vaultData` for preAuction storage node

Refs: #13

fix(liquidationVisibility): fix dependency errors

Refs: #24

fix(liquidationVisibility): fix race condition when running tests concurrently

fix(liquidationVisibility): fix test-vaultLiquidation.js

author anilhelvaci <anilhelvaci96@gmail.com> 1708371947 +0300
committer anilhelvaci <anilhelvaci96@gmail.com> 1708960452 +0300

fix(liquidationVisibility): lint fix

fix(liquidationVisibility): lint fix

fix(liquidationVisibility): lint fix

fix(liquidationVisibility): fix paths

fix(liquidationVisibility): lint and type fixes

fix(liquidationVisibility): lint fixes

…date dependencies

…ty (WiP)

…ara instead of state.

Refs: #15

…e for readability (WiP)

fix(liquidationVisibility): fix unit tests after rebase updates

…ests

Refs: #35

Refs: #35

…ty` in core-eval

Refs: #35

…s` and update tests accordingly

Refs: #35

Refs: #35

…ove `writeLiqVisibility`

Refs: #35

…onVisibilityWriters` resulted with below changes;

* Use `Promise.all` instead of `allValuesSettled`
* Remove `liq-rejected-schedule` and `liq-rejected-timestampStorageNode` as we don't need to handle those cases anymore
* Write an error message in postAuction and auctionResults recorder kits in the case of an error in distributing plans

Refs: #35

…lated artifacts.

Refs: #35

Refs: #35

Refs: #35

Refs: #35

Refs: #35

TODO: Update bootstrap tests as well

Refs: #35 #36

…sibility method and respective snapshot

…auctionResult with new data fields

Ref: #35 and #36

Refs: #35