This is an offshoot of #76.

There are some questions about whether active and disableInstrumentations config should be reloadable, or whether they should be static.

Currently, in the Node.js agent, starting the agent with active: false would skip instrumentation entirely. This means that it is not possible to dynamically "activate" the agent.

Elsewhere, users of the Java agent have assumed that setting active: false would completely disable the agent: elastic/apm-agent-java#639. Given the config's name, this is pretty a fair assumption. In that case it was due to metrics which we can fix, but still leaves a question about remote config polling in the future.

So, open questions:

• What should active: false do? Should this just disable event generation, or should it disable all code paths, including remote config polling?
  • If active: false disables remote config polling, should we have some other config that allows the agent to run "dormant" - polling remote config, but not generating events?
  • If active: false disables only event generation, should we have some other config which disables everything, including remote config polling?
• Should we have ternary state for disabling instrumentation? On, off (but possible to turn on), skipped entirely (never instrumented in the first place - cannot turn on).