Improve algorithm for sharing old orders

[albrow]

Fixes #638.

This PR introduces a new protocol for sharing existing orders between two peers, called the "ordersync" protocol. At a high-level, ordersync is a pull-based protocol rather than a push-based one. Upon initialization, a Mesh node will simply request orders from its peers. This PR also removes our old push-based strategy for sharing existing orders. GossipSub is now only used for sharing new orders.

The ordersync protocol is designed with forward-compatibility in mind and supports multiple "subprotocols" which define the details for what each request and response should look like. This PR includes only one subprotocol, in which all orders are returned using pagination. We can expand on this in the future to implement more efficient protocols (e.g. using cuckoo filters, a gossip layer, or prioritizing sharing orders with the best price).

Remaining TODOs:

• Modify peer scores based on what happens during the ordersync protocol.
• Add basic rate limiting to prevent abuse.
• Add support for filters. ordersync providers should only give you orders that match your filter, but they currently return all orders.

[albrow]

@fabioberger @jalextowle I believe I addressed all your feedback and any remaining TODOs on my end. I want to leave some optimizations and improvements for future PRs. This one is ready for final review.

I'll create new GitHub issues for any important tasks that are remaining.

[fabioberger]

Suggested change

	}).Info("received new valid order from peer via ordersync")
	}).Info("received new valid order from peer")

Let's not modify the log message since the data pipeline is querying for it exactly. If we want to distinguish between those discovered via ordersync and gossipsub, let's add a source field to the log.

[fabioberger]

Suggested change

	_, err := p.app.orderWatcher.ValidateAndStoreValidOrders(ctx, res.Orders, false, p.app.chainID)
	_, err := p.app.orderWatcher.ValidateAndStoreValidOrders(ctx, filteredOrders, false, p.app.chainID)

[jalextowle]

This snippet suggests that this array can have a random order (unless I'm missing something): https://play.golang.org/p/s3WTo2LVuyl. With this in mind, we aren't actually enforcing a preference on these subprotocols. What do you think about keeping the original subprotocols array in the Service object?

[albrow]

Arrays and slices do not have randomized order. Maps have randomized order. When we implement more subprotocols we just need to add an additional field to Service to keep track of the original order for the subprotocols that were passed in.

[jalextowle]

Your last sentence was the point of my comment. Is there a reason not to fix this now though?

[jalextowle]

I see that we parse the response below with the subprotocol, but I still question whether we should give a peer a psValidMessage peer score when we cannot decode their response as a valid rawResponse. This relates to the two other comments about not propagating the error.

[albrow]

This is addressed by the other changes. We only add the psValidMessage score when receiving a valid message.

[jalextowle]

Yep, I just wanted to mention this in case not returning the err was intentional.

[jalextowle]

This looks good to me once my outstanding comment is addressed