Create middleware system

[adamcharnock]

Required for #6 and #4.

This is going to have overlap with the plugin system. Either we should draw a clear distinction between the two, or we should remove the plugin sytem

[adamcharnock]

Let's have a go at mapping plugin hooks to middleware methods:

Plugin hook	Middleware method	Notes	Source
before_parse_args	?		init.py:88
receive_args	?		shell.py:43, run.py:79
before_server_start	start_server		client.py:313
after_server_stopped	start_server		client.py:329
before_rpc_call	send_rpc_call		client.py:443
after_rpc_call	send_rpc_call		client.py:466
before_rpc_execution	execute_rpc_handler		client.py:380
after_rpc_execution	execute_rpc_handler		client.py:399
before_event_sent	send_event		client.py:580
after_event_sent	send_event		client.py:583
before_event_execution	execute_event_handler		client.py:1041
after_event_execution	execute_event_handler		client.py:1091
exception	?		run.py:44
(does not exist)	receive_event
(does not exist)	receive_rpc_call
(does not exist)	execute_scheduled_task

So it looks like with a little more work we could replace the plugin system with the middleware system.

Important

It is important that calling fn() always results in the action being performed, and not just a coroutine being created. This is because the developer may wish to perform tasks after the action as run.

Therefore it would seem sensible that:

• async middleware methods should always await fn
• non-async middleware methods should not await fn

Lightbus will promise to pass appropriate callables in each case.