Add status support

[brendt]

I've noticed the Travis builds failing from time to time. To be able to debug this, I need more information about the pool. This PR adds a class which is used to print out the status of the pool as a test failing message.

An example of a failing build: https://travis-ci.org/spatie/async/jobs/323771446

Re-running builds fixes the tests, so it's not an easy to reproduce issue.

This debugger is a quick addition, but maybe can be improved upon in the future to be useful in real application too.

[brendt]

@freekmurze Are you ok with adding this to the codebase? It feels like a bit of a dirty fix to me, but it's the only thing I can think about to be able to debug this issue better in the future.

I noticed that xdebug is enabled on Travis, maybe there's way to replay the failing test with xdebug? That might be a better solution than adding this. Anyways, your feedback is appreciated.

[freekmurze]

Maybe add some helpers for outputting a title, a line, ...

[freekmurze]

Seems nice. We could make the API a bit more developer friendly:

• letting PoolDebugger holding an instance of Pool
• adding a factory like method on Pooldebugger to create an instance for a Pool (maybe a constructor is enough, but I tend to use static factory methods for these kind of things)
• adding a method on Pool to create a debugger.

So you can do things like

$pool->debugger()->status();
$pool->debugger()->summary();

or

$debugger = $pool->debugger();

$debugger->status();

Thoughts?

[brendt]

@freekmurze I was hesitant to tie a debugger instance to the pool, because it's not needed for the real functionality and makes the Pool class even larger, something I'd like to avoid. That's why I went with a simple helper class which can read and parse the status of the pool.

I would actually like to see some kind of PSR-compliant logging added in the future. I can see some advantages in using a logger over a static helper class. However I don't think it's a required featured for a first release, as I'd like some real user input first.

So that are my two arguments against adding an extra dependency to Pool itself. I actually believe the PoolDebugger class may be removed in the future. However, we do need a way to better debug failing builds before a 1.0 release, as it can signify an issue we're unaware of that needs fixing.

[freekmurze]

I'd still add such functionality to the Pool class. Maybe we should rename it to a something that sounds more first-class-citizen-like, eg status instead of `debugger?

[brendt]

status indeed sounds better. Are you ok with Pool creating a new PoolStatus instance on construct, and for now only implementing PoolStatus::__toString() which we can use in the test fail messages?

[freekmurze]

Sounds good to me!

[brendt]

@freekmurze Feel free to review the last changes when you've got the time :)

[freekmurze]

Nice!

[freekmurze]

You could opt to use PHP_EOL here.

[freekmurze]

You could opt to use array_reduce in order to avoid this temporary variable.