WL#9219: Remove cross compatibility code for binlog V1-V3

Affects: Server-8.0   —   Status: Complete

There are several versions of the binary log file format:
v1: Used in MySQL 3.23
v3: Used in MySQL 4.0.2 through 4.1
v4: Used in MySQL 5.0 and up
A v2 format was used briefly (in early MySQL 4.0.x versions),
but it is obsolete and no longer supported.

To support replication between different versions, there are some compatibility
code for converting old binlog format to new binlog format. According to the
support policy, v1 and v3 are out of the support period.

To make the code simple and readable, this worklog will remove the
compatibility code between binlog versions. And replication will just
support binlog v4 since this worklog.
No functional requirements

Non-functional requirements
NF1. Remove the compatibility code for supporting binlog v1 and v3.
NF2. Both slave and mysqlbinlog SHALL refuse to connect to Masters
     older than 5.0 which generate binlogs of v1 and v3.

- Error for server older than 5.0
  Slave shall report error ER_SLAVE_FATAL_ERROR with message:
  "Master reported unrecognized MySQL version".
  The error message already exists for unrecognized versions.

  mysqlbinlog shall report error with message:
  "Could not find server version: "
  "Master reported unrecognized MySQL version '%s'."
  The error message already exists for unrecognized versions.

- Remove support code for START_EVENT_V3 event
  MySQL server and mysqlbinlog will no longer recognize START_EVENT_V3.

  Both MySQL server and mysqlbinlog will report below error when they
  meet START_EVENT_V3 event type.
  "Found invalid event in binary log".
  The error message already exists for unknow event type.

No Interface change
- Start_event_v3 and Start_event_log_v3
  Both above classes will be removed. Some of the code will be moved into
  Format_description_event and Format_description_log_event.

- event_type_permutation
  Some binlog types' number was changed before 5.0. event_type_permutation is
  used to convert old type number to new one. That is not needed any more, since
  supported server will never generate old type number.

- Table map id field of Table_map_log_event uses 6 bytes since 5.1.5. Take map
  id just takes 4 bytes before 5.1.5 which is before 5.1 GA, so we can remove
  the compatibility code for 4B table map id field.