Handle empty extended queries

[Guflly]

Fixes #304.

Empty Parse messages now keep an empty statement instead of invoking the query parser. Describe and Execute return the protocol responses expected by PostgreSQL clients, including when handlers override the describe methods.

Tests:

• cargo test -p pgwire
• cargo test --test empty_extended_query
• cargo check -p pgwire --examples
• cargo check --manifest-path tests-integration/test-server/Cargo.toml
• cargo clippy -p pgwire --lib -- -D warnings

[sunng87]

for this api implementation, we will still need to check portal.statement.statement.is_none() or use a hard unwrap just like the examples. I wonder if we can avoid the Option<> in statement, and use a bool field in our Statement struct to indicate if a statement is empty.

WDYT?

[Guflly]

A bool would still need a value for S when parsing is skipped, which means parsing the empty query again or requiring S: Default. I kept the Option and handled None directly in the examples. Does that work for you?

[sunng87]

yes but without the bool, even if we can return EmptyQuery in our default handler implementation, the user will still need to deal with the Option and have duplicated EmptyQuery logic.

[sunng87]

A possible new idea is to update our PortalStore API to store empty query specifically. A breaking change at PortalStore is fine because it's rarely directly used in user code.