Unify daemon processes

[chingor13]

The BatchDaemon is great for submitting items in the background. We can abstract the concept of a job and leverage the job runner framework to support other job types - the primary example is supporting the Debugger daemon - a simple loop that uses long polling for results.

Currently, to use the debugger, you need to set up 2 daemon processes. By combining the daemons, the user only needs to set up a single daemon.

In this PR:

• Create new JobInterface
• BatchConfig is now JobConfig and stores JobInterface instances
• Introduce SimpleJob which is used for jobs with a single blocking method that runs in a loop.
• Fix a few method names in the Batch namespace to match our getter/setter naming convention.
• Debugger Daemon is now a simple job type and is registered when the first Agent is created - this removes the need for a separate daemon process

Example custom simple job:

class MySimpleJob
{
    use SimpleJobTrait;

    public function __construct()
    {
        $this->setSimpleJobProperties([
            'identifier' => 'my-simple-job'
        ]);
    }

    public function run()
    {
        while (true) {
            echo "looping\n";
            sleep(2);
        }
    }
}

[chingor13]

@jdpedrie @dwsupplee This is not ready for a full review, but does abstracting the job interface make sense to you? It allows for configuring other asynchronous jobs besides batch jobs (with an item message queue). The primary use case for now is to handle the debugger's breakpoint fetching loop (which currently must be run as its own separate daemon).

[dwsupplee]

@chingor13, sounds like a great direction to move towards. 👍

[chingor13]

@dwsupplee @jdpedrie @tmatsuo This should be ready for a look.

[tmatsuo]

I tried this branch on GAE Flex.

The code below

$batchLogger = LoggingClient::psrBatchLogger(
    'app',
    ['debugOutput' => false,
     'batchOptions' => ['workerNum' => 8],
     'clientConfig' => [
         'projectId' => getenv('GOOGLE_CLOUD_PROJECT'),
         'transport' => 'rest'
     ]
    ]
);

only spun up 2 child processes. Does it ring a bell?

[chingor13]

I had changed the parameter to numWorkers to be more clear. workerNum seems like it's the worker id number. We can change it back if we're concerned about breaking people who may have been using this feature.

[tmatsuo]

That's definitely it. Perfonally I'm fine breaking this, but I'll defer to @dwsupplee for decision.

The performance wise, the change has no problems at all.

[dwsupplee]

This is a nicely thought out improvement. Great work.

numWorkers sounds good to me. We have marked the batch feature as experimental everywhere so we have the leeway to make these kinds of improvements.

A few items:

• Should we have test coverage for the newly introduced Job related classes/traits?
• Will we need updates to accommodate for Introduce options to serialize closures for batch processing #886?

[chingor13]

I'll add some more tests for the new job classes/traits and will update to use the closure serializer.

[chingor13]

Hold off on merging this. The system test is failing and I'm looking into it.

[chingor13]

@dwsupplee The system test is fixed. The actual problem was from #887 where I had made BreakpointStorageInterface#load always return data rather than null/[] if the debuggee is not yet registered. This caused a timing issue because we started the breakpoint reporter with a null debuggeeId so the agent could not successfully send breakpoint data. The fix was to not start the breakpoint reporter agent until we receive a debuggeeId indicating that the debuggee has been registered.