[7.12.1-RC1] CoreConnectTimeoutError due to a crash in REST API Component

[kozlovsky]

If a component's start method throws an exception, it should lead to a Tribler Core shutdown for most components. However, with the current logic, the Core shutdown does not happen immediately; it is postponed until Tribler GUI can connect to Tribler Core and retrieve information about the Core exception to show the user a feedback dialog.

It works well for most components, but the REST API component is a special case. If the REST API component crashes with an exception, Tribler GUI will not be able to communicate with Tribler Core and retrieve the exception. Because of this, we can see the following behavior in case of exception in the REST API component:

1. Tribler GUI launches Tribler Core;
2. Tribler Core session starts components;
3. REST API component crashes with an exception;
4. CoreExceptionHandler remembers unreported_error to report it to Tribler GUI later when it can connect. The error is suppressed, and the Core continues to work.
5. EventRequestManager cannot connect to Tribler Core, as REST API is not working, and eventually raises CoreConnectTimeoutError.
6. The resulted error has no information about the actual reason for the error, as GUI was not able to connect to the Core

Examples:
https://sentry.tribler.org/organizations/tribler/issues/1352/events/daaa2a25ff0d46fd843a60bcbe83e4bf/
https://sentry.tribler.org/organizations/tribler/issues/1352/events/ec7fb3e184d3491ebd5d0c30f0476de1/

To reproduce the problem, you can switch to a release branch and raise an exception from the start method of RESTComponent.

To fix the issue, Core should shut down in case of an exception in RESTComponent. Then GUI will see that the Core is finished and can take the correct error traceback from the Core stderr. The simplest way to do this is to not add special handling to RESTComponent and to immediately shut down the Core on any exception in any component with the tribler_should_stop_on_component_error flag equal to True (currently, this flag leads to Core shutdown, but only after GUI successfully connected to Core).

The last Core stderr output does not necessarily contain the correct Core error traceback, as Core can write additional messages to stderr during the shutdown. To reliable retrieve the error, it is necessary to concatenate at least several latest stderr writes.