The ref count of an McdRequest is decremented along with self->delay 
every time _mcd_request_end_delay is called, and self->delay is initialised 
to 1 in the _init function for McdRequest. 

This means that McdRequest should be initialised with a ref count of 
1 + self->delay by the constructor-helper, but it currently is not
(the _constructed method should probably ref the object before returning 
it to do this).

However

_mcd_account_proceed_with_request() will call:

  _mcd_plugin_request_new (account, _mcd_channel_get_request (channel))

_if_ there are > 0 plugins which satisfy MCP_IS_REQUEST_POLICY (which is 
the case in the test suite): The object created by this holds a ref to 
the McdRequest.

_mcd_account_proceed_with_request() does not unref this object (stored 
in the plugin_api variable).

End result: if there are CP_IS_REQUEST_POLICY plugins, the ref count for
McdRequest objects will be right, for the wrong reasons, and we'll leak 
an McdPluginRequest.

If there are no such plugins (we don't ship any by default, I think)
then McdPluginRequest won't leak, but McdRequest objects will end up
getting freed too early.

Not sure how/if we could construct a test case for this. I guess 
running a test that involved a request in a copy of MC _without_ 
any request policy plugins would demonstrate that things were set
up right.