Add missing delayed readiness service handling to ServiceRegistry

[bit-shifter]

The pre-OSS version of ServiceRegistry catered for delayed readiness services (services that are either async or have a dependency on an async service).

This was previously handled via method #initialiseServices, which doesn't appear to have been ported across during the migration.

[dchambers]

@bit-shifter, did you end up doing this for us? If not, how have you worked around this problem in CaplinTrader?

[soruban]

CT is still using their ServiceRegistry which has the method.

We are having the same issue and anyone using, for instance, Permissioning & SLJS services would need this.

@bit-shifter suggested I patch the BRJS ServiceRegistry with the method, unfortunately the initialiseServices adds dependencies to DelayedReadinessService which is not in BRJS at present time, hence this would not be a viable patch to be pulled back.

For now, I just copied the content of the method into our Bootstrap class, once a way to handle this is added to BR, we will switch over.

[bit-shifter]

@dchambers Apologies for the late response on this one..

The method has not been ported into brjs, I don't believe that this is the correct thing to do longer term.

A better implementation to satisfy async service issue would be one that uses promises.

[dchambers]

I've just spoken to the CT team about this, and there are a couple of issues with the current approach:

1. The service alias is expected to point to a class that has a zero-arg constructor, and when then isn't possible the expectation is that the service will be provided on the client.
2. Some services can not be initialized synchronously, and we handled this in a really bad way by creating a DelayedReadinessService interface, which has a number of issues with it.

Instead, for BRJS we'd like to do the following:

1. Require all services to return promises regardless of whether they can be provided synchronously or not.
2. Expect the service alias to point to a module that returns the service, so any service class can be constructed, with our without arguments as necessary, and with no need to inject stuff in.

At this point, it becomes clear that we actually don't need a ServiceRegistry class at all, since a service is just an an aliased modules that returns a promise.

[andy-berry-dev]

@dchambers Is this something we should aim to add for 1.0?

[dchambers]

This issue has been superseded by #1128.