refactor: postponed removals and simplifications

[erights]

Staged on #8781

closes: #XXXX
refs: #8749 endojs/endo#1985 #8781

Description

Now that a recent endo is released and agoric-sdk has been upgraded to depend on it, we can finally get to a lot of agoric-sdk technical-debt cleanups that we've postponed. The cleanups in this PR include:

• Deleting redundant local copies of both types and code; instead importing them from the appropriate endo package.
• Deleting the entire @agoric/same-structure package, that had no remaining users anyway.

Security Considerations

Less code helps security. No other effect on security

Scaling Considerations

none. (or minor help due to smaller total code)

Documentation Considerations

Once these reductions are complete and we can delete legacy exporters, there will be less to document.

Testing Considerations

Of the redundant code copies here, the tests here a bit bigger than the ones in their new home. So endojs/endo#1985 will preserve this extra test code.

Upgrade Considerations

@ivanlei added you as a reviewer for advice on when it would not be too disruptive to merge this.

[erights]

@turadg , at https://github.com/Agoric/agoric-sdk/actions/runs/7591791789/job/20680380230?pr=8771#step:4:361 I'm getting one block of type errors I'd like your help on. These errors only happen indirectly in the @agoric/casting package. There are no such errors in the packages these things are imported from. Nor in any other packages that import them. What's special about @agoric/casting?

[erights]

At endojs/endo#1933 (comment) , I ask about possible interaction with some endo side changes that were also waiting until after the endo-agoric-sdk sync.

[turadg]

What's special about @agoric/casting?

Nothing particularly special. Each package is a separate TypeScript project so they each resolve differently (see #4404 as a spike to unify).

In this case @agoric/casting has a package search depth of 2 (maxNodeModuleJsDepth) and that leads to import some types that themselves have dependencies, which cannot be found because they require searching deeper.

We rely on searching because of the decision years ago to rely on ambient types. The more we use type modules (with imports and exports) the less we'll have this problem.

One reason it's happening in your PR is that making @agoric/assert depend on @endo/errors increased the search depth necessary to resolve the the assert type. So moving more to @endo/errors helps. I've pushed 6e0290e including that.

The change also reduces the maxNodeModuleJsDepth to 1, shrinking the type import graph. That caused another problem, with ThisType in @agoric/notifier but I punted that with ts-ignore and XXX comment justifying it.

Separately, your "cleanups in this PR" list has several items but so far it's all in one commit. Please consider separating the changes by commit. It will be easier to review that way.

[erights]

Separately, your "cleanups in this PR" list has several items but so far it's all in one commit. Please consider separating the changes by commit. It will be easier to review that way.

The vast majority of the bulk were changing imports, and use of the assert global, to instead import from appropriate endo packages. All that has not been moved to #8781 . Done.

[Chris-Hibbert]

This looks fine to me.

My impression of the current intended process is that we can merge changes to master as they get approved, and the hard version compatibility questions will be answered as we decide when to migrate to a release branch. @warner, is that a correct reading of the theory?

[erights]

@Mergifyio requeue

[mergify]

requeue

✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically