Assume all calls to Chelonia are async

[corrideat]

Problem

Currently, there's no difference between Chelonia and application state, and they both share the same Vuex store.

When #1981 is implemented, Chelonia will be moved into a service worker (or at least, it can be assumed to be running in a service worker). The recent addition of the * selector to sbp makes this relatively easy to implement and all calls to chelonia/ can be relatively easy be sent to the service worker. However, because web pages communicate with the service worker asynchronously, this means that all calls to chelonia/ selectors must now be assumed to be asynchronous.

This means that all frontend code making use of synchronous Chelonia selectors must be refactored to work with asynchronous selectors. ChatMain.vue is one file that makes heavy use of synchronous chelonia/ selectors and will be affected by this, but it's not the only part of the app that's affected.

Summary of changes

Anything using a Chelonia selector in the frontend (this does not include contracts for now, and does not include Chelonia itself, nor does it include the server), such as anything with a .vue extension must assume that sbp('chelonia/...') will return a promise.

Good: await sbp('chelonia/doSomething'), sbp('chelonia/doSomething').then(() => { ... }).catch(() => { ... })
Bad: sbp('chelonia/doSomething')

This does not affect other selectors (except actions, but those are already asynchronous) and does not affect getters and setters, or anything to do with the Vuex state. The Vuex state and the Chelonia state are kept in sync using a different event-based mechanism. This means that sbp('state/vuex/state') is fine and it doesn't need to be await sbp('state/vuex/state').

Solution

Identify use of synchronous Chelonia selectors (ChatMain.vue is a good place to start) and refactor it to work with promises. This means that, for example, initialising the local chatroom state that's used for rendering can no longer be done synchronously.