Traffic speed test depends on non-deterministic snapping behavior

[daniel-j-h]

The following test depends on random behavior and how snapping works out:

osrm-backend/features/testbot/traffic_speeds.feature

Lines 86 to 117 in f355826

	Scenario: Weighting based on speed file weights, ETA based on file durations
	Given the profile file "testbot" extended with
	"""
	api_version = 1
	properties.traffic_signal_penalty = 0
	properties.u_turn_penalty = 0
	properties.weight_precision = 2
	"""
	And the contract extra arguments "--segment-speed-file {speeds_file}"
	And the customize extra arguments "--segment-speed-file {speeds_file}"
	And the speed file
	"""
	1,2,1,0.27777777
	2,1,1,0.27777777
	2,3,27,7.5
	3,2,27
	1,4,1
	4,1,1
	"""
	And the query options
	| annotations | datasources |
	When I route I should get
	| from | to | route | speed | weights | a:datasources |
	| a | b | ab,ab | 1 km/h | 20020.73,0 | 1:0 |
	| a | c | ab,bc,bc | 2 km/h | 20020.73,741.51,0 | 1:1:0 |
	| b | c | bc,bc | 27 km/h | 741.51,0 | 1:0 |
	| a | d | ab,eb,de,de | 2 km/h | 20020.73,378.17,400.41,0 | 1:0:0 |
	| d | c | dc,dc | 36 km/h | 956.8,0 | 0 |
	| g | b | ab,ab | 1 km/h | 10010.37,0 | 1:0 |
	| a | g | ab,ab | 1 km/h | 10010.36,0 | 1 |
	| g | a | ab,ab | 1 km/h | 10010.36,0 | 1:1 |

There is no way to g (see the network a bit above) and @MoKob pointed out snapping at b could be eb or ab. The test failure is currently on the mld/alternatives branch but it's not the cause for it (it's not hitting the alternatives code path at all).

Here's the test diff:

https://travis-ci.org/Project-OSRM/osrm-backend/jobs/237850494#L2198

cc @danpat for non-deterministic snapping behavior

[TheMarex]

The whole test case should be rewritten using a node map and a more obvious graph structure.

[oxidase]

The test case fail is not related to snapping and shows a data race in the assignments

osrm-backend/src/updater/updater.cpp

Line 230 in 42f3401

fwd_weights_range[segment_offset] = new_weight;

and

osrm-backend/src/updater/updater.cpp

Line 263 in 42f3401

rev_weights_range[segment_offset] = new_weight;

during parallel segment weights update