pgsql: Consistently enforce tsvector/tsquery maximum lengths.

Consistently enforce tsvector/tsquery maximum lengths.

Some places rejected individual tokens longer than MAXSTRLEN, while
others rejected ones longer than MAXSTRLEN-1. The data structure is
perfectly capable of handling MAXSTRLEN, so there's nothing wrong
with using the looser bound. Moreover, as things stand there is a
dump/reload hazard: some code paths permit construction of a tsvector
or tsquery that would later be rejected by tsvectorin or tsqueryin.
So standardize on using MAXSTRLEN.

Identical remarks apply to MAXSTRPOS (the total data length),
so fix that too.

Back-patch, in hopes of avoiding cases where a value acceptable to
one supported release is not acceptable to another.

Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Reviewed-by: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com
Backpatch-through: 14

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/ef9063a8870fb5fb1666da3399ff666201eccf70

Modified Files
--------------
src/backend/tsearch/ts_parse.c | 4 ++--
src/backend/utils/adt/tsquery.c | 6 +++---
src/backend/utils/adt/tsvector.c | 4 ++--
src/backend/utils/adt/tsvector_op.c | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)