BUG/MINOR: peers: don't use remote table definitions from a previous session

BUG/MINOR: peers: don't use remote table definitions from a previous session

The remote table ID and the list of data types announced by the remote
peer in table definition messages are stored in the shared table and are
never reset when the session ends. Since remote_id defaults to 0, a table
switch message designating table ID 0 selects any table the peer never
defined, and after a reconnection, a table switch message referencing a
table ID defined during the previous session selects it with the previous
session's data types, without the checks performed on definition messages
(e.g. the key type).

In both cases the update that follows is still decoded: the entry key is
inserted into the local table even when no data type is announced, so such
a peer can create entries carrying only a key and no value. On a small
table this can evict legitimate entries.

Let's reset the remote definitions when the session ends, and never match
table ID 0 in switch messages.

Reproducibility: both issues require a received "stick-table switch"
message (type 131). HAProxy has never emitted this message: since the
peers protocol 2.0 was introduced in 2015 (b3971ab06), the function in
charge of building it, peer_prepare_switchmsg(), actually emits a table
definition message (type 130), and doc/peers.txt documents type 131 as
unused. However, the message is part of the documented protocol and its
type is still assigned, so a third-party or modified implementation may
well emit it, possibly in good faith, since its name and semantics
describe exactly a table selection by ID. It is therefore reachable by a
non-HAProxy peer, but not by any version of HAProxy itself.

Note that the statement in the original report about a conforming peer
which "always defines a table before switching to it" does not hold
either, as HAProxy never switches at all.

This must be backported as far as 3.0.