Re: BUG #17379: Cannot issue multi-command statements using a replication connection

I wrote:
> [ assorted whining about replication-command lexing ]

The business with unstable results turned out to be due to failure
to reset the lexer's start state, so that's a one-line fix that I
already pushed.  Attached is the patch I propose to fix the rest
of it.

The core of this is deciding that we cannot try to run repl_scanner.l
over the whole input string when it is not a replication command.
That's just going to leave us chasing a moving target of what it has
to know to lex successfully.  If it were designed to never have any
lexer failure conditions, maybe this could be made to work, but that
ship already sailed.  Hence, what this does is to lex just the first
token, see if that's one of the replication-command keywords, and if
so push it back so that repl_gram.y will succeed.  If not, we just
punt immediately without examining any more of the string.  This
gets rid of all of the other failure conditions discussed, and allows
deletion of nearly as much code as it adds.  Notably, we don't
need the SQLCmd node type anymore, since repl_gram.y will never be
asked to look at a general SQL command.

Note: I put the switch() recognizing command-starting keywords into
repl_scanner.l.  I'd tried to put it in walsender.c, which seemed
like a more natural place, but the keyword token names aren't
currently exported outside repl_gram.y + repl_scanner.l.  Moving
them to a header file seems like way more work than is justified.
You'd have to touch repl_scanner.l anyway while adding a new
command keyword, so this arrangement isn't terribly awful.

I also failed to resist the temptation to clean up some poor style
in repl_scanner.l, as well as bad decisions like not having
the same idea of what's whitespace as the core lexer does.

The part about removing the SQLCmd node type can't be back-patched
(since we can't renumber enum NodeTag in stable branches), but
I don't see any reason the rest of this can't be.

			regards, tom lane