Dynamic Config (required for pull services, eg. SQS workers)

[jsuresh]

The two modes of operation are 'push' (that is, connect via a http proxy) and 'pull' (eg, pool of workers taking jobs of SQS).

The second isn't supported cleanly - the proposal is

1. Change 'endpoints' (in config) to 'connections' or similar - they can be HTTP, as well as some bit of dynamic config
2. If there is dynamic config, it's the appserver's job to periodically re-read this. Open to discussion if this should be all config, and as part of the run config, we have start/stop/reload-config, or a subset of specifically scoped config that the app periodically polls itself.

[paul-thompson-helix]

Propose that we keep 'endpoints' concept and ADL types as-is and add the new dynamic config idea as eg:
activations

Where an activation can have endpoints & dynamic configs optionally...

[paul-thompson-helix]

Possibly:

Update ProxyModeConfig to push endpoints one level down

struct ProxyModeConfig  {
    StringMap<Activation> activations;
    // ...
};

Activations can be an endpoint and/or a set of configurations attached to the activation:

struct Activation {
    Maybe<EndPoint>  endpoint;
    Vector<ActivationContext> activationContexts;
}

Where ActivationContext is like the current DeployContext but with a Json json option:

struct ActivationContext {
    String name;
    ActivationContextSource source;
}

union ActivationContextSource
{
    // Literally provided object for mustache interpolating
    Json json;

    // Context from a local file
    FilePath file;

    /// Context from an S3 object
    S3Path s3;

    /// Context from AWS secrets manager secret
    String awsSecretArn;
};

(Either making a separate ActivationContextSource or repurposing DeployContextSource?)

[paul-thompson-helix]

See #79

See #80