refactor trade facilitation mechanism

[edchapman88]

Current Mechanism:

• loop through trader id's
• get_trader_by_id from grid
• edit the inventory of the trader to execute the trade
• use set_object_location to put the trader back into the grid at the position it was in before
  • this overwrites the old version of the trader in the grid at that location
  • THIS COULD BE A PROBLEM IF MULTIPLE AGENTS WERE IN THAT GRID LOCATION
• crucially, call self.agent_grid.update() before doing any further operations on the grid

Proposed mechanism to look into:

• use the .apply_to_all_values() method on the grid (which takes a closure)
• a draft of this approach is included in 34-rl-trader, but currently commented out

[sgreenbury]

Update:

• To reduce interaction with agent_grid during trading process, simplified trading is implemented so one trade at most per agent occurs in before_step()
• Calls to update() are expensive when running without visualization. Instead updates can be done with set_object_location() (these do equality on the agent based on agent.id() so can safely be called on agents in the same loc) and a lazy_update() instead used in the Board update.

[sgreenbury]

Looking a bit more into the way the scheduler works, it looks like the trading needs to all be done within the trader. See the following lines of the scheduler as the scheduler processes events on agents without looking at the grid and using versions of the agent from the previous step.

Initial implementation (6720cb0) of trading inside agent using:

• A lookup on the board to keep track of the pairs
• Reading from the grid (board state at start of step) with get_traders_read to get the "before_step" view of the traders locations, inventories, offers.