Add remote configuration worker

[lloeki]

What does this PR do?

Implement a polling worker for remote configuration.

Motivation

Remote configuration

Additional Notes

This is a simple generic polling worker:

• pass it a block via new and it'll call it every interval
• it can be stopped and started in a thread safe way

There is no fork protection: it is supposed to start on demand when the first request comes in.

How to test the change?

Example to use it in conjunction with the remote configuration client is below.

Note that the agent may not reply immediately with a full configuration, but it happens eventually.

  require 'ddtrace'

  Datadog.configure do |c|
    c.agent.host = '192.168.135.133'
    #c.tracing.enabled = true
    #c.diagnostics.debug = true
  end

  transport_options = {
    agent_settings: Datadog::Core::Configuration::AgentSettingsResolver.call(
      Datadog.configuration
    )
  }

  require 'datadog/core/transport/http'

  transport_v7 = Datadog::Core::Transport::HTTP.v7(**transport_options.dup)

  require 'datadog/core/remote/client'

  client = Datadog::Core::Remote::Client.new(transport_v7)
  repository = client.instance_eval { @repository }
  
  require 'datadog/core/remote/worker'
  
  worker = Datadog::Core::Remote::Worker.new(interval: 10) do
    client.sync

    puts '========='
    pp repository
    puts '========='
  end

  worker.start
  sleep 100
  worker.stop
  
  repository.contents

[lloeki]

Pending:

• specs
• RBS typing

[lloeki]

Rebased using git rebase --onto add-remote-config-client 08eff6e^ add-remote-config-worker

[lloeki]

Rebased using git rebase --onto add-remote-config-client cc025a9^ add-remote-config-worker

[GustavoCaso]

Rebased using git rebase master

[lloeki]

Maybe a few things could be improved

[GustavoCaso]

at_least(:once) because calling worker.stop, which happen on the after block, will also call acquire_lock && release_lock

[ivoanjo]

Consider perhaps making the mutex a dependency that can be injected (via the constructor) to avoid having to set expectations on the class being tested.

Something along the lines of

      class Worker
        def initialize(interval:, mutex: Mutex.new, &block)
          @mutex = mutex

[GustavoCaso]

I had it that way before.

I don't mind having to set expectations for the class being tested. Especially if the API does not break, if in the future we use a different class than mutex, we could change the underlaying lock mechanism without having to change the class initialise arguments or test.

[ivoanjo]

Left a few notes, nothing blocking! :)

[ivoanjo]

Minor: Since this runs on a background thread, you may want to log if it exits with an exception

[ivoanjo]

Minor: Consider naming this thread (on Ruby 2.3+) -- this will show up in the profiler clearly, as well as in other debugging tools

[ivoanjo]

Consider perhaps making the mutex a dependency that can be injected (via the constructor) to avoid having to set expectations on the class being tested.

Something along the lines of

      class Worker
        def initialize(interval:, mutex: Mutex.new, &block)
          @mutex = mutex

[ivoanjo]

Minor: Having both queue and result seems a bit redundant -- consider maybe using expect(queue.pop).to be 1

[GustavoCaso]

Thanks for the suggestion. Will make sure to change it in a follow up PR

[GustavoCaso]

@ivoanjo Thanks for all the suggestions. I'm going to go ahead and merge it, but I will get back to those in a follow-up PR 😄

[ivoanjo]

Yup, sounds good :)