handle leading slashes in KV keys

[koeninger]

closes #1560

[ispivey]

@koeninger is this a breaking change or not? Could you demonstrate that it is or isn't with some tests? cc @xortive

[koeninger]

@ispivey shouldn't be a breaking change. I added an additional unit test demonstrating that if someone was working around the bug by encoding, this won't double encode. Here's a manual test as well of this patch vs the latest released wrangler:

leading slashes behavior is fixed:

bash-3.2$ wrangler kv:key get --namespace-id=0ee4a606a6124cd9a36cc0bb7a45b7ea "/leadingslash"
⚠️ Code 10009: get: 'key not found'
�️ Run wrangler kv:key list to see your existing keys

bash-3.2$ cargo run -- kv:key get --namespace-id=0ee4a606a6124cd9a36cc0bb7a45b7ea "/leadingslash"
Finished dev [unoptimized + debuginfo] target(s) in 0.22s
Running target/debug/wrangler 'kv:key' get --namespace-id=0ee4a606a6124cd9a36cc0bb7a45b7ea /leadingslash
someval

non-leading slashes behavior is unchanged:

bash-3.2$ wrangler kv:key get --namespace-id=0ee4a606a6124cd9a36cc0bb7a45b7ea "has/slash"
someval

bash-3.2$ cargo run -- kv:key get --namespace-id=0ee4a606a6124cd9a36cc0bb7a45b7ea "has/slash"
Finished dev [unoptimized + debuginfo] target(s) in 0.60s
Running target/debug/wrangler 'kv:key' get --namespace-id=0ee4a606a6124cd9a36cc0bb7a45b7ea has/slash
someval

[ispivey]

LGTM, thanks for demonstrating that it won't unexpectedly change behavior for existing working values 👍