Use ErrorBoundary for attachment renderer

[compulim]

Fixes #3760.

Changelog Entry

Fixed

• Fixes #3760. Use <ErrorBoundary> to wrap around attachment renderer, by @compulim in PR #3761

Description

When rendering attachment, we should add an <ErrorBoundary> (or friendlier <UserlandBoundary>) to catch all exceptions.

Design

Attachment middleware is the only "legacy" middleware. Similar to "modern" middleware, we are adding <ErrorBoundary> to wrap around the rendering of middleware.

"Legacy" middleware has a signature of:

(...initArgs) => next => (...renderArgs) => (React.Element | false)

// `initArgs` are arguments for initializing the middleware
// `renderArgs` are arguments for render-time

"Modern" middleware has a signature of:

(...initArgs) => next => (...setupArgs) => ((...renderArgs) => React.Element) | false

// `setupArgs` are arguments for setting up the renderer, at this point, the middleware must decide if the component should be rendered or hidden

The modern signature allow the renderer to know beforehand that if an element should be rendered or not. This help transcript and other containers to count how many elements it is going to render. This information is crucial for some operations, such as grouping activities.

If the middleware "agreed" to render, it must return a React.Element when we call its render function, (...renderArgs) => React.Element.

In future, we should move attachment middleware to use the modern middleware signature.

Specific Changes

• Added applyMiddleware.forLegacyRenderer for "legacy" middleware
  • The generic applyMiddleware() is left as-is as it could be used by non-React middleware (where <ErrorBoundary> should not be applied)
• Using the applyMiddleware.forLegacyRenderer for constructing the attachment renderer
• Added tests for unknown activity command

• I have added tests and executed them locally
• I have updated CHANGELOG.md
• I have updated documentation

Review Checklist

This section is for contributors to review your work.

• Accessibility reviewed (tab order, content readability, alt text, color contrast)
• Browser and platform compatibilities reviewed
• CSS styles reviewed (minimal rules, no z-index)
• Documents reviewed (docs, samples, live demo)
• Internationalization reviewed (strings, unit formatting)
• package.json and package-lock.json reviewed
• Security reviewed (no data URIs, check for nonce leak)
• Tests reviewed (coverage, legitimacy)