allow extension factories to be asynchronous

Title: allow extension factories to be asynchronous

Context:

• at the moment, extension factories must implement a synchronous create*(config) method, assuming that a given configuration itself is enough to return a ready-to-use extension instance or *FactoryCb. E.g.
  • envoy.access_loggers: AccessLog::InstanceSharedPtr createAccessLogInstance(config)
  • envoy.filters.http: Http::FilterFactoryCb createFilterFactoryFromProto(config)
  • envoy.filters.network: Network::FilterFactoryCb createFilterFactoryFromProto(config)
  • envoy.filters.listener: Network::ListenerFilterFactoryCb createListenerFilterFactoryFromProto(config)
  • etc

Problem:

• in the context of Wasm extensions, config object itself is not enough to return a ready-to-use extension instance or *FactoryCb, e.g.
  • Wasm code needs to be loaded from a remote location
  • Wasm extension is allowed to define _start / proxy_on_vm_start / proxy_on_configure callbacks that, in a general case, might need to use async Envoy API, such as HTTP Client / gRPC Client
• right now, envoy.access_loggers.wasm, envoy.filters.network.wasm and envoy.filters.http.wasm implement create*(config) method in a way that lets Envoy to proceed and start serving requests even though Wasm extension has not been loaded, configured and warmed yet

Proposal:

• change extension factory interfaces to return a Future/Promise instead of a ready-to-use object
• it will give Wasm extensions flexibility in deciding when they are ready-to-use
• it will make Envoy behaviour consistent - the enclosing object (e.g., Listener) will remain in the warming state until all extensions are actually ready-to-use
• it will simplify user/operator experience with wasm extensions. It's a burden for users to decide whether it's ok to serve requests while the extension is not ready yet. Just don't serve the requests until configuration is complete.