Do follow-up requests on incomplete type responses

[eboasson]

When Cyclone issues a type lookup request for a type T and all its dependencies, it necessarily includes only those dependencies that is aware of. The types learnt from the response may themselves introduce unknown dependencies.

That means that wait_for_type_resolved_impl_locked may have to issue follow-up requests.

@dpotman Perhaps you can have a look? I'm not sure this is the best way to do it. It does the trick for dynsub on dyntype but that doesn't mean it is good. I'm particularly worried that it could possibly result in a request storm, and that would be quite bad.

[dpotman]

This approach is similar to the type resolving as a result of endpoint matching, in case a proxy endpoint's type is not fully resolved. A difference is that endpoint matching is retried only when a type that is (a dependency of) the endpoint's top-level type gets the resolved state, so a follow-up request will only be sent if there are new dependencies.

In the solution in this PR, a type lookup request is sent each time the condition variable is triggered, which could potentially lead to a large number of requests in case other (non-related) types are resolved when wait_for_type_resolved_impl_locked is waiting for dependencies to become resolved and the condition is triggered. The comment in ddsi_type_get_gpe_matches suggests that resolving dependencies should be triggered from the type lookup reply, which I think will also solve the issue for wait_for_type_resolved_impl_locked.

When handling a reply, we could gather all unresolved dependencies for the types in the reply, and send a request for these types. But what if the request for the type was done explicitly without including deps? We could keep a status requested or requested with deps for a type, but that complicates the administration a bit. And what if an unresolved dependency was already requested, but was not in the reply, should that type be requested again?