#2330: lock respondents in ChannelBroker

[anaPerezGhiglia]

Main changes

• Lock respondent when activating next queued contact in ChannelBroker
  • This is necessary since some of the actions triggered when activating a respondent may end up modifying it
• Edit tests that were asserting received messages (either by the Channel or the ChannelBroker). Replace assert_received with assert_receive which "asserts that a message matching pattern was or is going to be received within the timeout period" (see doc)
  • This was necessary since the ChannelBroker process now may need to wait for the respondent lock to be granted

Bonus track

• Update "Surveda Layers" docs to reflect current state

closes #2330

[ysbaddaden]

@anaPerezGhiglia Is this meant to ensure that another actor won't modify the respondent while we're trying to contact them? Otherwise only the expired callback is supposed to update the respondent (ask/setup shouldn't).

[anaPerezGhiglia]

Is this meant to ensure that another actor won't modify the respondent while we're trying to contact them? Otherwise only the expired callback is supposed to update the respondent (ask/setup shouldn't).

@ysbaddaden yes, it's true that nuntium_channel and verboice_channel do not end up modifying the respondent, but actually the channel_broker doesn't know that... that's why I decided to leave the Respondent.with_lock for both scenarios (ivr and sms)

[ysbaddaden]

I'd consider it surprising for the channels to modify the respondent, I'd expect them to try to push the contact and failures to bubble back to the channel broker. But just protecting against a parallel modification is a good enough reason to lock it!

Just in case: expiring the contact doesn't also try to lock the respondent (or it's reentrant)?