migrate to @endo/errors package

[dckc]

What is the Problem Being Solved?

assert is a global in SES. However, IDEs don't know about it or its members. To allow automatic imports we have @agoric/assert, but it's useful outside of Agoric.

Description of the Design

Move most of @agoric/assert to use @endo/errors. Move NonNullish checked cast to @agoric/internal.

Acceptance

No more use of global assert in agoric-sdk. This will support getting assertion functions without having set up a SES environment.

[dckc]

@erights the little justification I was able to find on this was not sufficient to convince @turadg : #5673 (review)

[dckc]

@turadg as we discussed, I added a note to our Coding Style:

Note: pending resolution of #5672, within agoric-sdk, let's use the SES global rather than importing from @agoric/assert.
That is: use const { details: X, quote: q} from assert;.

[turadg]

@abebeos can you expand on what your interest is in whether @agoric/assert exists? It has no impact on SES or Endo.

[erights]

Hi @abebeos , appreciated. This outstanding question is indeed technical debt we need to resolve. Currently we use both styles:

const { details: X, quote: q } = assert;

vs

import { details as X, quote as q } from '@agoric/assert';

Aside from history, I don't see any good reason for these to coexist. We should consistently use one or the other. In addition, the @agoric/assert, as its name implies, exists at the agoric-sdk level, not the endo level, making it impossible to adopt it for general use without deeper intervention.

@turadg , do your reasons for keeping @agoric/assert still apply to our system after all the work you've done repairing our types? Are these reasons strong enough that you think we should move it to @endo/assert and adopt it everywhere? If not, can we repair whatever the remaining reasons are for @agoric/assert and then deprecate it, for eventual removal?

FWIW, for new code, I always use the assert global rather than the @agoric/assert package and have never noticed any resulting pain.