Refactors code to support inheritance

[anuragagarwal561994]

At present everywhere there are checks for whether the queue is bull or not based on which the functionalities differ.

In this PR, this task have been properly handled by using classes and inheritance where by which all the bee related logic goes in bee.js and all the bull related logic in respective bull.js.

If another queue has to be integrated in future, it will be so much easier to just write another implementation which implementation details which affecting the core functionalities of the UI.

This makes the code more concise, easy to understand and extendable without extra if else conditions.

Three classes are mainly used:

1. Queue: which holds the actual queue within it and provides a common interface for the application to react on function calls.
2. Job: acts as an adapter for jobs for different queue implementation.
3. JobData: represents not the actual job object but just the data that can be exposed to UI, JSON or anywhere else.

[skeggse]

Looks like an awesome refactor to me!

I didn't filter my suggestions as well as I could have based on existing code vs new/refactored code; feel free to dismiss suggestions if you think they're out of scope.

How did you test these changes/can you describe the potential risks?

[skeggse]

Can we have these abstract methods throw a not implemented exception? This would both make it clear that these should be overridden, and avoid weird cases down the road where we instantiate a Job but avoid the constructor.

[anuragagarwal561994]

Done, just check once. Didn't use a message because the stacktrace should already cover the method name from where the error originated.

[anuragagarwal561994]

@skeggse Just wanted to confirm why have return void res.**json type changes have been added?

[anuragagarwal561994]

@skeggse A thorough testing is still required, I did testing with just bull queue of some of the basic functionalities that I was using. I thought to first get a review done before we can move onto complete testing again together.

There should not be any potential risks associated as such, in this code refactor I carefully converted all the if and else statements to different classes. Not sure if I understood your statement here correctly.