* Put LD_LIBRARY_PATH set back into Linux `nix-shell`
...as we need it for `ghci` workflows inside the shell(s).
* Add (failing) test case to check MetadataMap ordering
* Remove SortedList value-component from MetadataMap
...which fixes the failing test case introduced by `85a2d13`.
This is a potentially breaking change that warrants a library rev bump.
I'm not sure what the original reason was for the sorted list component of
`MetadataMap` (i.e., header values), but that implementation choice makes it so
that determining the "last provided" header value associated with a duplicate
key cannot be recovered. That is, it is in violation of this requirement from
the [spec](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md):
```
Custom-Metadata header order is not guaranteed to be preserved except for values
with duplicate header names.
```
I'm guessing that the original motivation might have been to ensure that the Eq
instance was not sensitive to ordering of values for duplicate keys.
I think we can drop the existing `Eq` assumption about order-insensitive values
for duplicate keys (there is order sensitivity after all), and if we end up
discovering a common use case for an order-insensitive equality on values, we
should address that via a utility function (instead via the type's `Eq`
instance).
So, this commit changes the value component of the `MetadataMap` type to be a
list of `ByteString` values instead of `SortedList ByteString`, and removes the
`sorted-list` package as a dependency, as it has no other uses in the library.
Note that this commit is not claiming we are now spec-compliant w.r.t. header
treatment after this change. In particular (and at least),
1. We do not yet support base64-encoded binary data via the special `-bin` key
suffix.
2. As far as I am aware, we do not (yet) interpret comma-separated header values
the same as duplicate header keys for each of those values.
3. As far as I am aware, we do not (yet) do any validation of header names nor
whitespace handling as per the request grammar from the spec.
* Extend Arbitrary MetadataMap to explicitly encode key duplication
Duplicate keys were allowed by the previous implementation, but this commit
makes key duplication more explicit and more frequent.
* Add metadata map ordering QC prop
* Drop qualified use of @?= since it's so common in this module
* Extend checkMetadataOrdering to check instance Eq MetadataMap
...and use the appropriate bracketing wrapper.
* Relocate MetadataMap type to its own module
* Add some helper functions for MetadataMap lookup; documentation
* Extend testMetadataOrdering w/ use of lookup{All,Last}
* Bump grpc-haskell{,-core} -> 0.2.0
e1091b9c0d