Implements https://github.com/quicwg/base-drafts/pull/3917

When the type field in a long header packet is corrupted from Handshake
to Initial, the payload length field is instead interpreted as token
length which leads to failure when we try to actually parse the payload
length.

Instead use the `drop_pkt_on_err()` trick when parsing the payload
length fails.

Fixes #614.

This updates how PTO and loss timeout are calculated based on the latest
recovery draft. It also fills in some gaps we had, notably arming PTO
when the peer has not completed address validation to prevent deadlocks
during handshake.

When a STREAM frame is received and `get_or_create()` is called, we
assume that the stream was not created locally.

However it can happen that a locally-created stream was already
collected and then duplicated data for it is received.

This means that we should check whether the stream was destroyed, before
validating the stream ID.

The crypto_test_data.cc file is huge, but it is outside of the src/
directory so we can easily exclude it.

This is a regression introduced by 74458c6d.

We need to check that there are outstanding packets that need to be
acked before trying to create an ACK frame, otherwise a panic is
triggered when the frame is serialized.

We only need Android NDK to build quiche for Android platform.
Simply use rust image from Travis and install NDK on top of it.

It should be more or less the same as master, but it also has a less
strict build configuration and doesn't require go and perl for build.

Fixes #589.

Previously, when doing stateless retry the C example server would
reuse the dcid for new_scid. Once a client sent back the token
and we validated it, a new connection ID would be generated and
sent back to the client as part of the handshake. The client would
detect an error when validating retry_source_connection_id and
close the connection.

This change aligns the C examples to the Rust examples. A new
connection ID is generated and sent in the retry. Once a client
sends back the toked and we validate it, we use the information
at hand instead of generating anything again.

Fixes #566 and #582.

According to the docs.rs documentation "no-default-features = true" is
the correct field https://docs.rs/about#metadata

This should hopefully fix building the documentation on docs.rs.

This fixes an issue with `--release` Windows builds of rust packages using quiche as a dependency (and quiche stand-alone, if built with custom configurations).

What happens (at least in my case) is that cargo builds the dependencies without debug symbols for release builds of a Rust package (i.e. builds with symbols only the root package).
If `quiche` is one of those deps, it gets built `--release` but without the debug symbols, and cmake-rs consistently puts boringssl in a `<somepath>/Release` directory, instead of the `<somepath>/RelWithDebInfo` directory expected by `build.rs` which then fails with the dreaded `could not find native static library 'crypto', perhaps an -L flag is missing?`.

This code synchronizes the behaviour of `build.rs` with [the one included in cmake-rs](https://github.com/alexcrichton/cmake-rs/blob/master/src/lib.rs#L553); in this way it should supposedly work with all the configurations currently supported by cmake-rs on Windows using the msvc compiler chain.

Instead of always sending 2 PTO probes, we should start by sending one
probe, and increase to 2 if the previous probe was lost.

This is done by using the current PTO count to determine how many probes
should be sent (up to 2).

In 39905083 we implemented support for retransmitting unacked data in
PTO probes if no new data is available.

However after discussion it seems that prioritizing new data is not
actually necessary, and simply retransmitting old data first might be
the better strategy (if anything it's easier to implement).

This reverts the changes from the previous commit, and simply implements
logic to reschedule the frames from the 2 oldest sent packets when the
PTO expires.

Besides having a much simpler implementation, this also has the
advantage of allowing other frames to be sent in the probe packet (e.g.
ACKs), without risking that the original data frame wouldn't fit in the
output packet, since we won't retransmit CRYPTO and STREAM frames as-is
but will go through the normal packetization procedure (including e.g.
respecting STREAM priorities).

This also means that we won't retransmit the same data in both probe
packets. Though if there aren't enough packets with data frames
available we might still end-up sending a PING frame only in the second
probe packet.

Move Android helper scripts into tools/android.
No functional changes.

This is for consistency with the rest of the project, and to make shell
completion less annoying.

No functional changes.

Some indirect dependency requires a newer Rust version to build:
https://github.com/BurntSushi/aho-corasick/issues/62

Currently when sending a PTO probe we either include new data frames or
a PING frame in the packet to make sure that the probe is ack-eliciting.
However if no new data is availabe, we should try to include old data
that has not been marked as lost yet if there is any, instead of just
sending a PING.

This changes that by iterating over old sent packets (that have not been
acked or lost yet) and copying CRYPTO and STREAM frames into the outgoing
packet when creating PTO probes.

This requires cloning the frames, which is somewhat unfortunate, but it
should only happen when PTO expires, which has exponential backoff so it
shouldn't be possible to use this as a DoS vector.

This also changes the error used when the stream limit is exceeded as
per the latest draft.

Also slightly refactor existing check to avoid repeating the same
constant over and over.

Fixes #565.

This builds on top of the QUIC-level priority support.

This change adds a new method `send_response_with_priority()`to
the HTTP/3 API. This takes a `priority` argument, a string that
contains the Extensible Priority header field value formatted
as Structured Headers e.g. "u=2, i". The contents of `priority`
is used for scheduling when sending response body bytes with
`send_body`.

The Extensible Priority scheme defines the defaults u=3 and i=?0.
Providing an empty value for `priority` will cause the defaults
to be used. The existing method `send_response()` has been updated
to send responses using defaults.

At this time, once a response is initiated it's priority cannot
changed.

No new API method is provided for clients to set request priority.
Clients can provide the `Priority` HTTP header in the `Headers`
argument of the `send_request()` method. This will be passed through
unmodified.

The quiche-client and quiche-server applications have been updated...

Other implementations running in the interop runner have higher timeouts
which kind of puts us at a disadvantage.

In the future we might want to make this configurable, but for now there
is not much point.

Featuring fixes by @LPardue.

This implements a very simple scheme for stream prioritization at the
transport layer. Each stream can be prioritized with an urgency level (a
number from 0 to 255 where lower is more important), as well as an
"incremental" flag.

Internally, instead of keeping a single queue for all scheduled streams,
an ordered map of lists is used instead. Each list holds the streams
that are scheduled at a given urgency level. When flushing data, the
non-empty list with the lower urgency level is used first.

Each urgency list is in turn split into two queues, one for
non-incremental streams, that are flushed fully in a FIFO order, and one
for incremental ones that are round-robined. Non-incremental streams at
the same urgency level take priority.

Currently priority is only used when flushing streams to the wire, but
not when streams are reported as readable or writable to the application
(yet).

Re-prioritization is not implemented yet.

Fixes #556.

rustfmt is yet again broken in the latest nightly, so pin the rust
version to the last known good one.

Can revert once https://github.com/rust-lang/rust/issues/73200 is fixed.

I realized that until other implementations update to draft-29 we will
fail the Retry tests, so we might as well do this now.

It's mostly just a matter of propagating the version from the public API
exposed to applications, down to where the retry integrity tag is
generated.

Unlike the initial salt, we only support the keys from the latest
version, as supporting Retry for multiple versions would require
changing the public API.

This adds support for selecting the initial salt depending on the
protocol version that was negotiated.

During version negotiation we also need to derive the initial secrets
again, as the new version might use a different salt.

When an application enables key logging in the Config object, quiche
will automatically read the SSLKEYLOGFILE variable and create the
corresponding file to log to.

However this is slightly dangerous as the application is not necessarily
in control of the environment variable, so keys might accidentally end
up being logged without the application saying so. And it generally
doesn't seem to be good form for a library to depend on environment
variables.

The current API is also not very flexible, as it only allows
applications to log to files, and doesn't allow enabling/disabling
logging on a per-connection basis.

So, in addition to calling `log_keys()` on the Config object,
applications now also need to call the `set_keylog()` method on each
connection they wish to log keys for, passing the `Writer` object that
will receive the actual data from quiche.