Avoid more null-errors in isosurface and mesh handling

[philippotto]

The meshes UI could provoke errors when viewing a dataset without segmentation layer or when update-permissions are missing (for example, in view mode).

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• I tested the cross-product of the following factors:
  • dataset with and without segmentation layer (I used ROI2017_wkw and data_types)
  • open dataset in view mode, with a hybrid and with a skeleton-only annotation
• In each constellation:
  • make sure the "load centered isosurface" behaves correctly (it should only be disabled if there is no segmentation layer). if the centered cell is 0, the button is available, but should emit a warning toast.
  • the import buttons are only enabled if allowUpdate is true
  • importing an meshes/isosurface STLs should "work as expected". see here for sample STLs.

Issues:

• fixes "Load Isosurface for centered cell" throws error when there is no segmentation layer #5106
• fixes Importing mesh in view mode doesn't work #4935

---

• Updated (unreleased) changelog
• Updated (unreleased) migration guide if applicable
• Updated documentation if applicable
• Adapted wk-connect if datastore API changes
• Needs datastore update after deployment
• Ready for review

[daniel-wer]

LGTM 👍

In #4935 you wrote:

Related: this error only appears in a very obscure report in airbrake: https://scm.airbrake.io/projects/95438/groups/2835680766133594723?tab=notice-detail

Instead of [object Object], there should be a proper error message. I suggest to investigate this, too, before fixing the actual problem, since it's crucial to have robust error reporting.

Were you able to have a look at that as well? :)

[philippotto]

Related: this error only appears in a very obscure report in airbrake: https://scm.airbrake.io/projects/95438/groups/2835680766133594723?tab=notice-detail
Instead of [object Object], there should be a proper error message. I suggest to investigate this, too, before fixing the actual problem, since it's crucial to have robust error reporting.

Were you able to have a look at that as well? :)

Good point! I investigated this and if the sagas crash, the try-catch-block potentially receives the rejection reason of a promise, which doesn't need to be an error instance. for this case, the default stringification would produce [object object]. I fixed this by applying json.stringify when necessary. It's a bit of a bummer that rejection reasons and errors seem to be mixed in the catch-clause, but I cannot think of a more elegant solution right now.