* fix: nocache feature code rot
The MBChunk::snapshot code when using the "nocache" option no longer
compiles - this commit updates it to match the not(nocache) code.
* build: use updated broken_intra_doc_links name
The broken_intra_doc_links lint was renamed
rustdoc::broken_intra_doc_links
https://doc.rust-lang.org/rustdoc/lints.html
The is no specification logfmt, most implementations only unescape `\"` and leave
`\n` as is when parsing. Some implementations like go-logfmt do escape newlines as `\n` (and other chars
according to Go's escaping rules).
This PR just escapes non-printable characters using rust's string literal rules; they are not perfect but
they don't seem to be worse than other players.
(If this bites us some more we will probably be better of switching to json log output format and then equip ourselves with some simple shell scripts to reformat the logs on the fly while we're streaming them from k8s)
As a bonus point, this effectively simplifies the escaping code, possibly also speeding it up a bit
since it doesn't have to call replace twice (although I don't know what magic would the rust compiler have done to this double replace).
Closes#1791Closesinfluxdata/k8s-iox#1
Closes#1252
I defer to #1252 for the wider context; the "why" this escaping rule is the likely the right one (the "official" logfmt is particularly light on the spec side)
This PR, implements the following interpretation of the escaping rules:
1. To put a double quote in a double quoted string, you need to escape the double quote with a backslash: `"` -> `"\""`.
2. To put a backslash in a double quoted string, you need to escape the backslash with another backslash: `\` -> `"\\"`.
3. To put a character sequence `\"` inside a double quoted string, you need to combine the previous two rules: `\"` -> `"\\\""`
These rules are quite reasonable and follow the escape rules of most languages.
The test strings are correctly parsed by https://github.com/brandur/hutils,
Logs and traces are emitted via one pipeline. For now, it is not
possible to emit both, but it should be possible in a few weeks, as
tokio/tracing/tracing-subscriber is going through some refactoring recently.
All affected flags are well-documented, and I have tested all but the
OTLP output flags.
chore: clippy happy
chore: revert instrumentation changes
feat: add log format logfmt, log destinations stderr, stdout
chore: clippy happy
* fix: test_helpers crate should only be a dev-dep
* fix: object_store no longer has a build script, so no longer needs a build dep
* chore: Alphabetize all Cargo.tomls