Implement compatibility date and flags.

[kentonv]

Update: This feature has landed in the Wrangler 1.19.0 release. Note that previous releases will silently ignore compatibility_date and compatibility_flags, so be sure to check wrangler --version to make sure you have 1.19.0 or newer before trying to use this.

This adds support for a new part of the Workers upload API in which the developer may specify a "compatibility date" and one or more "compatibility flags". These settings affect behavior of certain Workers Runtime APIs, especially in cases where the API was originally introduced with a bug, and the bug could not be directly fixed because some deployed workers might be depending on it.

Setting the compatibility date opts your worker into exactly the behavior as it was on that date, guaranteeing that bug fixes introduced later will not break you. If you don't set a compatibility date, the default is the date when your named worker was first created. In the future, we will recommend all workers set an explicit date to avoid confusion.

Compatibility flags can further augment behavior by opting into upcoming bug fixes that aren't on by default yet, or opting into old buggy behavior even when your compatibility date is current. Most people won't use this -- it's mainly useful for testing, and as an escape hatch.

Compatibility level is controlled by adding one or two lines to wrangler.toml, like:

compatibility_date = "2021-07-12"
compatibility_flags = [ "formdata_parser_supports_files" ]

This example sets the "compatibility date" to July 7, 2021. The Workers Runtime API will mostly behave as it did for new Workers created on that date. However, this example also sets the additional flag formdata_parser_supports_files. This flag fixes a bug in the FormData API: Currently, the FormData parser converts uploaded files to strings. With this flag set, it correctly represents them as File objects, as required by standards. This change couldn't just be rolled out for everyone automatically, because it is possible that some Workers in production are relying on the conversion to string today, and we wouldn't want to break them. Currently, formdata_parser_supports_files can only be enabled by specifying it as a flag. However, at some date in the future, we will make it the default. Workers which set compatibility_date to that date or later will then get the fixed behavior.

For those interested, as of this writing, two compatibility flags exist:

• formdata_parser_supports_files: Parsing FormData, e.g. with request.formData(), will correctly represent file uploads as File objects instead of strings.
• fetch_refuses_unknown_protocols: fetch() will throw an error if the URL's protocol is anything other than http: or https:. Previously, it silently replaced other protocols with http:.

As of this writing, since we haven't yet chosen specific dates for these flags to become default, compatibility_date does not yet have any effect. However, you must set a date in order to use flags.

[kentonv]

Note: I couldn't find any tests that test other types of metadata that pass through directly from wrangler.toml to the upload API. This is the first time I've ever written Rust, so I am not very comfortable striking out and introducing all-new tests. But, if I missed something and there is a good place to insert these tests with existing examples to follow, I'm happy to do it, just tell me where to look.

(I did test these changes against the real production API, and they worked.)

[jyn514]

Unrelated to your change, but it bugs me that there are so many spurious clones here, Metadata could hold references instead of owned values. build_form should take an owned value too since it's always used with &owned_assets and clones the fields.