multiplayer: a player works a train, not a car - and put the corrections right

Second live test. Four things, three of them the same mistake seen from
different angles: the session was reasoning about single vehicles where it
should have been reasoning about trains.

- a peer may now operate anything coupled into the set it is sitting in. This
  is what "cabchangebackward rejected: not a member of the crew of that
  vehicle" was: the crew was recorded against one car of a four-car unit, and
  the cab switch addressed another
- every vehicle gets a network id, not only the ones worth driving. Commands
  are addressed by that id, and a player has to be able to walk into any car
  of their train. "peer 3 cannot take en71-017rb_4: no such vehicle in this
  session" was the driving trailer of an EN71 - a full desk, no engine, and
  nobody assigned to it, so the old test missed it. Having a driving position
  is what counts now, engine or not
- the roster groups vehicles into the trains they are coupled into and the
  lobby lists one row per train. Coupling is worked out afresh every time, so
  a train that comes apart becomes two, and because a crew entry sits on the
  car its player occupies, each half keeps the people who were riding in it
- walking to another car of your own train is not a new claim and asks nothing
  of the crew capacity, which counts people per train

Positional correction never actually did anything: it identified a track by
name, and most track in a scenery has none, so the lookup returned nothing and
place_on_track() was never reached. The client sat 178 m out of place for
minutes, reporting four vehicles "put back on the rails" every time while
moving none of them. Tracks now travel as their index in the path table, which
comes from the scenery file and is therefore the same on every peer.

Also from the test:

- the camera jumped in and out of the cab on the client whenever the host
  reversed, because the correction was forcing the server's CabActive and
  CabOccupied onto it. Which cab somebody sits in is theirs alone - two people
  sharing a vehicle each have their own - so it is no longer replicated
- the correction no longer touches the control positions of the train the local
  player is working. Their crew's commands reach every peer on their own, and
  snapping a lever back a fraction of a second after it was moved is what made
  the reverser look dead
- the frame buffer was sized for the old lockstep, up to sixty frames deep.
  Every frame in it is input lag, so it is down to twelve with a target of one
- asking the AI of a vehicle to step aside is given five tries and then said
  once, instead of every thirty frames forever; and a resync request now has a
  real cooldown

network/network.h

@@ -101,9 +101,12 @@ namespace network
 		size_t reconnect_delay = 0;
 
 		const size_t RECONNECT_DELAY_FRAMES = 60;
-		const float MAX_BUFFER_SIZE = 60.0f;
+		// the queue of authoritative frames waiting to be played out. every frame sitting
+		// in here is a frame of delay between pressing a key and seeing it happen, so it
+		// is kept as short as the connection allows rather than a comfortable second deep
+		const float MAX_BUFFER_SIZE = 12.0f;
 		const float JITTERINESS_MIX = 0.998f;
-		const float TARGET_MIN = 2.0f;
+		const float TARGET_MIN = 1.0f;
 		const float TARGET_MIX = 0.98f;
 		const float JITTERINESS_MULTIPIER = 2.0f;
 		const float CONSUME_MULTIPIER = 0.05f;
@@ -113,10 +116,13 @@ namespace network
 		// how far out of place a correction found us, in a row. a full resync is only
 		// worth asking for when the routine stream is not catching up on its own
 		int bad_corrections = 0;
+		uint64_t last_resync_tick = 0;
 		static constexpr double RESYNC_POSITION_ERROR = 25.0;
 		static constexpr int RESYNC_BAD_CORRECTIONS = 5;
+		// a correction needs time to take hold; asking again before it has is pointless
+		static constexpr uint64_t RESYNC_COOLDOWN_TICKS = 600;
 
-		float last_target = 20.0f;
+		float last_target = 2.0f;
 		float jitteriness = 1.0f;
 		float consume_counter = 0.0f;