This branch updates the console crates' dependency on `tonic` to v0.8.0
and `prost` to 0.11.0.

In addition, I've added a [`cargo xtask`][xtask] command for manually
regenerating the generated protobuf bindings.

This is necessary as the current approach, regenerating the bindings in
an integration test, does not work when the protos fail to compile
(which they do after the Tonic update). Since running the crate's tests
requires compiling the crate, if the proto bindings don't compile, we
can't re-run the test.

[xtask]: https://github.com/matklad/cargo-xtask

This changes the console CLI's error handling so that GitHub issues are
only suggested for panics, not for recoverable errors (such as "no
config file found", "couldn't connect to remote host", etc).

This way, if running a subcommand panics/errors, we still get nice
`color-eyre` reports.

This commit adds `color_eyre`'s default backtrace frame filters, so we
skip stuff that's not relevant.

This adds a dump of all the console's config options to the issue
metadata for GitHub issues generated using `color_eyre`'s GitHub issue
generation on panics.

<details>

<summary>Example issue Markdown:</summary>

## Error
```
lol
```

## Metadata
|key|value|
|--|--|
|**version**|0.1.6|
|**config.subcmd**|`None`|
|**config.target_addr**|`Some(http://127.0.0.1:6669/)`|
|**config.env_filter**|`None`|
|**config.log_directory**|`Some("/tmp/tokio-console/logs")`|
|**config.retain_for**|`None`|
|**config.view_options.no_colors**|`false`|
|**config.view_options.lang**|`Some("en_US.UTF-8")`|
|**config.view_options.ascii_only**|`Some(false)`|
|**config.view_options.truecolor**|`Some(true)`|
|**config.view_options.palette**|`Some(All)`|
|**config.view_options.toggles.color_durations**|`Some(false)`|
|**config.view_options.toggles.color_terminated**|`Some(false)`|
|**location**|tokio-console/src/main.rs:36:5|

</summary>

<a name="0.4.0"></a>
## 0.4.0 (2022-08-10)

#### Breaking Changes

*  Update `tonic` to `0.8` (#364) ([40e2f6f](40e2f6f))

#### Features

*  Update `tonic` to `0.8` (#364) ([40e2f6f](40e2f6f))

<a name="0.1.7"></a>
## 0.1.7 (2022-08-10)

#### Features

*  Update `tonic` to `0.8` (#364) ([40e2f6f](40e2f6f))
*  Update `console-api` to `0.4` (#364) ([40e2f6f](40e2f6f))

<a name="0.1.7"></a>
## 0.1.7 (2022-08-10)

#### Features

*  include config options in autogenerated issues (#365)
   ([fcb54df](fcb54df))
*  filter out boring frames in backtraces (#365) ([523a44a](523a44a))
*  init error handling before subcmds (#365) ([6646568](6646568))
*  only suggest opening issues for panics (#365) ([23cb6bf](23cb6bf))
*  update `tonic` to `0.8` (#364) ([40e2f6f](40e2f6f))
*  update `console-api` to `0.4` (#364) ([40e2f6f](40e2f6f))

Needed for #374.

This configures clippy to ignore most of the generated code in
`console-api`.

Due to a change in the unstable task builder APIs, this no longer
compiles with the latest version of Tokio. Fortunately, it's a simple
fix.

<a name="0.1.7"></a>
## 0.1.8 (2022-09-04)

#### Bug Fixes

*  fix build on tokio 1.21.0 (#374) ([0106407](0106407))

Fixes: #372

`--ascii-only true` shows ascii
`--ascii-only false` shows emojis

if `--ascii-only` is not passed, default value will be true, shows emojis

Currently, the documented `cargo-run` in README no longer works, as now
there are two binaries:

```console
$ cargo run
error: `cargo run` could not determine which binary to run. Use the `--bin` option t
o specify a binary, or the `default-run` manifest key.
available binaries: tokio-console, xtask
```

This branch declares the `tokio-console` binary as the [`default-run`]
value in the `Cargo.toml`, so it is now run by default by `cargo run`.

Alternatively, we can just update the README line with `cargo run --bin
tokio-console`

[`default-run`]:
    (https://doc.rust-lang.org/cargo/reference/manifest.html#the-default-run-field)

Fixes #382

Found via these commands:

    codespell .
    markdownlint *.md --disable MD013

Currently, the help text for the `r` and `t` keystrokes to switch to the
Resources and Tasks views is shown on the Task Details and Resource
Details views, as well as on the Task List and Resource List views.

See this screenshot for an example:
![image](https://user-images.githubusercontent.com/2345750/202058962-4a8f062c-78fd-47eb-a3b1-5de470976aa8.png)

However, the keystrokes are not actually handled while the console is
showing a details view.

This branch changes the console to handle the `r` and `t` keystrokes on
all views. This also simplifies the keyboard input code somewhat.

Build and add to the released binaries for `aarch64-unknown-linux-gnu`,
`aarch64-apple-darwin` and `aarch64-pc-windows-msvc`

Hey I noticed this out of date in my `Cargo.lock`, and since I didn't
see any PRs/issues open doing so already, figured I'd open one!

Signed-off-by: hi-rustin <[email protected]>

Signed-off-by: hi-rustin <[email protected]>

Fixes #393

Co-authored-by: Eliza Weisman <[email protected]>

Fixes #386

Signed-off-by: hi-rustin <[email protected]>

The durations in the tokio-console UI are shown with a unit, so the
digits after the decimal separator are generally not relevant. Since
space is at a premium in a terminal UI, it makes sense to cut down where
possible.

This change removes all digits after the decimal separator in the tasks
table view. In the task detail view, 2 decimal places are kept.

Additionally, 4 new duration formats are added to represent
minutes-with-secondsi, hours-with-minutes, days-with-hours and days.
These are only applied once the leading unit is greater than zero.

For example, 59 seconds will be shown as seconds: `99s` and then 60
seconds will be shown as minutes-with-seconds: `1m00s`. New colors have
been chosen for each format.

NOTE: I had to make a small unrelated change in
`task::Details::make_percentiles_widget` to make clippy happy.

Fixes: #224

The `color-eyre` crate was previously on version 0.5. This version
depends on `tracing-subscriber` 0.2, meaning that we had 2 different
veresions of `tracing-subscriber` in our dependency tree.

This change updates `color-eyre` to 0.6, which depends on
`tracing-subscriber` 0.3, the same as `console-subscriber`.

Tokio Console generates its own sequential Id for internal tracking and
indexing of objects (tasks, resources, etc.). However, this Id will be
recreated if Console is restarted.

In order to provide more useful information to the user, the task Id
generated by Tokio can be used in the task list and task details screens
instead. If used in this way, the ID field in the task list and task
detail views will be stable across restarts of Console (assuming the
monitored application is not restarted).

This also frees up horizontal space, as the `task.id` attribute
doesn't need to be displayed separately.

The disadvantage of using Tokio's task Id is that it is not guaranteed
to be present by the type system.

To avoid problems with missing task Ids, the Tokio task Id is store in
addition to the `span::Id` (used to communicate with the
`console-subscriber`) and the sequential console `Id` (used in the
`store`). If a task is missing the `task.id` field for whatever reason
it will still appear, but with an empty ID. If multiple runtimes are
active, then duplicate ID values will appear.

Fixes: #385

Co-authored-by: Eliza Weisman <[email protected]>

Add support for console connections that use Unix domain sockets rather
than TCP.

Closes #296.

Co-authored-by: Eliza Weisman <[email protected]>

The Console API specifies sending task busy duration only for completed
polls, it doesn't include the time spent in the current poll if the task
is active.

Tokio Console then calculates the busy time including the time spent in
the current poll - based on the last poll start and poll end times sent
by the Console Subscriber.

However, there was an error in the logic which determined when a task is
being polled for the purpose of calculating the busy time. The logic
only considered the first poll, when there was no recorded end poll time
at all.

This change adapts the logic so that it also considers the case where
the last recorded poll start is later than the last recorded poll end.
This indicates that the task is being polled.

Co-authored-by: Eliza Weisman <[email protected]>

There are 2 widgets which display the poll times for a task in the
detail view. The poll times percentiles are always displayed and if
UTF-8 is available, then a sparkline histogram is also shown to the
right.

The logic for displaying these two widgets is quite long and is
currently interspersed within the `render` function for the task detail
view plus helper functions. Additionally, it is not easy to add a second
set of widgets showing the time between waking and being polled for a
task which is planned for #409.

This change factors out that logic into separate widgets.

There was already a separate widget `MiniHistogram`. Some of the logic
that was previously in the task detail view has been moved here.

A new widget `Percentiles` has been added to encapsulate the logic for
preparing and displaying the percentiles.

A top level `Durations` widget occupies the entire width of the task
detail view and control the horizontal layout of the `Percentiles` and
`MiniHistogram` widgets. The new widget will also supress the histogram
if there isn't at least enough room to display the legend at the bottom

Each task displays the sum of the time it has been idle and busy, as
well as the total. The idle time includes the time between when a task
is woken, and when the runtime actually polls that task.

There are cases where a task may be scheduled for a long time after
being woken, before it is polled. Especially if many tasks are woken at
the same time and don't yield back to the runtime quickly.

To add visibility to this, the total time that a task is scheduled
before being polled has been added. Additionally, a new task state
`Scheduled` has been added. This is displayed in both the tasks table
and in the task detail view.

In the `console-api`, the total `scheduled_time` for the task has been added to
the `TaskStats` message in `tasks.proto`.

This is the first of two parts. In the second part (#409), a histogram for
scheduled time will be added, the equivalent of the poll time histogram
which is already available on the task detail screen.

To show a pathological case which may lead to needing to see the
scheduled time, a new example has been added to the `console-subscriber`

## PR Notes

This PR does something adjacent to what is described in #50, but not quite.

The unicode character used for a `SCHED` task is ⏫.

The second PR (#409) will record a scheduled time histogram the same as it
recorded for poll times. These two changes should go in together (and certainly
shouldn't be released separately). However, this PR is already quite big, so they'll
be separated out.

The idea is that this PR isn't merged until the next one has also been reviewed
and approved. It would be good to get some feedback at this stage though.

The task list view with the new column for `Sched` time:

<img width="1032" alt="a tasks table view for the long-scheduled example" src="https://user-images.githubusercontent.com/89589/232456977-2921f884-4673-420f-ba4f-3646627d44db.png">

The `Task` block in the task detail view showing the new `Scheduled` time entry.

<img width="510" alt="The task block on the task detail view for the rx task in the long-scheduled example" src="https://user-images.githubusercontent.com/89589/232457332-e455e086-9468-42c9-8fda-7965d8d1e6f8.png">

In Rust 1.69.0, the `almost_swapped` lint was enhanced and now triggers
on the clap 3.x `Subcommand` derive macro. Unfortunately the macro
includes `#[deny(clippy::correctness)]` (which implies denying
`almost_swapped`), and so it can't be overridden.

This issue doesn't exist in clap 4.x, it was fixed already.

Until either the fix is backported to clap 3.x or we switch to clap
4.x., this change fixes the Rust version used for clippy (and by
extension rustfmt) to the previous version 1.68.2.

Co-authored-by: Eliza Weisman <[email protected]>

Display the scheduled time percentiles and sparklines for the histogram
of scheduled times. The schduled time is the time between when a task is
woken and when it is next polled.

The scheduled time, which was already calculated, is now stored in a
histogram and sent over the wire in together with the task details.

This is used to draw percentiles and sparklines on the task details
view, in the same way that is done for the poll times histogram.

The refactoring done in #408 has been used to more easily display two
sets of durations (percentiles and histogram where possible).

## PR Notes

The PR depends on both #406, which adds initial support for recording the
scheduled (wake-to-poll) time, and #408, which refactors the percentile and
histogram widgets to make them easier to reuse.

It shouldn't really be reviewed in depth until those two have been merged as
it contains a lot of duplication and will need to be rebased.

Here are some examples of the scheduled times durations on the task detail view:

<img width="1037" alt="task detail view for the sender task in the long-scheduled example" src="https://user-images.githubusercontent.com/89589/232608774-d8ac48a7-3fe7-4742-a75b-e11bdb23abaa.png">

<img width="1043" alt="task detail view for the burn task in the app example" src="https://user-images.githubusercontent.com/89589/232608864-637f4f52-d4a6-468d-88fc-8fe1d53fdff9.png">

The enhanced `clippy::almost_swapped` lint which shipped in Rust 1.69.0
was triggering in some cases where we derive `clap::Subcommand`. It
wasn't possible to allow it, because a deny on `clippy::correctness`
(which implies `clippy::almost_swapped`) was present in the generated
code.

As a result, we had to fix the version of Rust used for Clippy to
1.68.2.

In clap_derive (included in clap) 3.2.25, the deny on `clippy::correctness`
has been removed and an allow for `clippy::almost_swapped` has beed
added. Fixing the forced clippy error.

This change updates clap to the latest 3.x version, including
clap_derive and clap_lex.

It also reverts the change made in #413, so we will go back to using
the latest version of Rust for `clippy` and `fmt`.

Bumps [h2](https://github.com/hyperium/h2) from 0.3.13 to 0.3.18.
- [Release notes](https://github.com/hyperium/h2/releases)
- [Changelog](https://github.com/hyperium/h2/blob/master/CHANGELOG.md)
- [Commits](hyperium/h2@v0.3.13...v0.3.18)

---
updated-dependencies:
- dependency-name: h2
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

We maintain separate changelogs for the `tokio-console`, `console-api`,
and `console-subscriber` crates.

Currently, changelogs are generated using the [`clog`] CLI tool.
However, `clog` does not support generating separate changelogs for
different subdirectories of a repo, so the current release process for a
given crate requires generating a changelog for the whole repo since the
last tag, and then manually editing it to remove changes to other
crates. This is a pain.

The [`git-cliff`] changelog-generating tool supports generating a
changelog that only includes commits that modified specific paths in the
repo. This means it can be used to generate separate changelogs for each
crate automatically, unlike `clog`. It's also much more configurable,
and we can use it to generate changelogs that have somewhat nicer
formatting (IMO).

This branch changes changelog generation from using `clog` to use
`git-cliff`, and regenerates all the existing changelogs. The included
`bin/update-changelog.sh` shell script updates the changelog for a given
crate to the provided tag. This will make the release process much less
complicated. 

A subsequent PR will add a shell script that handles updating crate
versions, generating the changelog, and publishing the crate and tag, so
that a release can be published by running a single command.

[`clog`]: https://github.com/clog-tool/clog-cli
[`git-cliff`]: https://git-cliff.org/

Currently, the Nix `flake.nix` pins the nixpkgs version to
`release-21.11`. This branch of nixpkgs includes `rustc` v1.56.1, which
is too old to build `tokio-console`. This means that Nix users using the
flake cannot actually build the console.

This branch unpins the nixkpgs version, allowing Nix users to build with
the latest `rustc`.

This branch adds a new `release.sh` script in `bin/` that can be used to
publish releases of console crates by running a single command. This
makes our release process require less effort, and also ensures that all
necessary steps are always performed when releasing a crate.

This commit updates the Tonic dependency for `console-api` from v0.8 to
v0.9.

BREAKING CHANGE:

This is a breaking change for users of `console-api`, as it changes the
public `tonic` dependency to a semver-incompatible version. This breaks
compatibility with `tonic` 0.8.

This commit updates the `console-subscriber` and `tokio-console` crates'
`tonic` dependencies to 0.9. This is not a breaking change to these
crates.

This is `tonic` 0.9's MSRV, so we must update our minimum Rust version
as well.

The screenshots in the README, which are also used in in the
`tokio-console` page on docs.rs were a bit outdated. The UI has changed
a bit since they were created.

This change updates the screenshots to be based on the latest UI from
the `main` branch.

This reverts commit 4f71484. This
commit breaks the existing docs, because it deletes images that are
linked in the current `docs.rs` documentation for `tokio-console`. Also,
we probably ought to resize the images so the text doesn't get scaled.

In the future, when adding new screenshots, let's make sure not to
delete the existing ones, because their GitHub URLs are referenced by
prior versions of the docs (cc @hds).

We should probably figure out a nicer image hosting solution
eventually...

The screenshots in the README, which are also used in in the
`tokio-console` page on docs.rs were a bit outdated. The UI has changed
a bit since they were created.

This change updates the screenshots to be based on the latest UI from
the `main` branch.

All previous versions of `tokio-console` on docs.rs reference the images
on the main branch, so it is important that they remain unchanged. The
new screenshots have been added to a sub-directory of the `assets`
directory named after the next version: `tokio-console-0.1.8`.

Signed-off-by: Eliza Weisman <[email protected]>

Signed-off-by: Eliza Weisman <[email protected]>

Signed-off-by: Eliza Weisman <[email protected]>

In #421, the screenshots in the `tokio-console` README were updated to
match the current code. The contents of the README also go into the
docs.rs page.

This change updates the two screenshots in the README in the root of the
repository. They now match the UI shown by the current code at the
latest release of `tokio-console`, 0.1.8. The screenshots are a little
bit wider than the ones in the `tokio-console` README as the example
`app` from the `console-subscriber` crate was used as the instrumented
application and the source file paths are longer.

The screenhots are now using relative links directly to the files in the
repository.

Additionally, the help text in the main README has been updated to
reflect what `tokio-console` now produces. This includes additional
descriptive text and also mentions how to connect to a Unix domain
socket.

The sparklines histogram used to visualize poll times and scheduled
times renders a legend for both axes. On the horizontal axis, it
displays the durations for the minimum and maximum buckets. On the
vertical axis, it displays the bucket count minimum and maximums.

Unfortunately, the minimum values for each axis are places together,
which can be confusing:

```text
╭Poll Times Histogram─────────────────────────────────╮
│46█                                                  │
│  █                                                  │
│  █                                                  │
│  █                                                  │
│  █ ▂                                                │
│  █▁█▇▃▁▁           ▁     ▁▁                      ▁ │
│ 031.23µs                                      7.11ms│
╰─────────────────────────────────────────────────────╯
  ^|----|
  │  ╰─ This is the minimum bucket duration value
  ╰── This is the minimum count
```

This can be confusing because it looks like there is an erroneous
leading zero on the minimum bucket duration.

If the minimum value is not zero, then the vertical axis minimum is
updated, but the bottom of the sparkline still represents zero. This
sitaution is unlikely, I had to add a fixed value to the bucket counts
to generate the histogram below.

```text
╭Poll Times Histogram─────────────────────────────────╮
│32██                                                 │
│  ██▇    ▁               ▁   ▁  ▁ ▁                  │
│  ███▇▆▆▆█▇▆▇▆▆▆▆▆▆▆▇▆▆▆▆█▆▇▆█▆▇█▆█▇▇▇▆▇▇▆▇▆▆▇▆▆▆▆▆▇ │
│  ██████████████████████████████████████████████████ │
│  ██████████████████████████████████████████████████ │
│  ██████████████████████████████████████████████████ │
│2033.79µs                                   536.58µs │
╰─────────────────────────────────────────────────────╯
 ^^|----|
  │  ╰─ This is the minimum bucket duration value
  ╰── This is the minimum count
```

This is probably misleading.

This change removes the minimum label on the vertical axis entirely.
This removes the confusion around the "erroneous" leading zero and since
the bottom of the graph is always zero anyway, it should be clear to
users without having to add the label.

The resulting histogram looks like:

```text
╭Poll Times Histogram─────────────────────────────────╮
│27 █▄                                                │
│   ██                                                │
│   ██                                                │
│   ██                                                │
│   ██▂                                               │
│  ▃███▃▁ ▁      ▁▃ ▃▃▃▁▃▅▁▃ ▃▃▃▃▃▁▁▁   ▁  ▁         ▁│
│  28.93µs                                   811.01µs │
╰─────────────────────────────────────────────────────╯
```

See https://github.com/tui-rs-revival/ratatui/wiki/Migrating-from-TUI

Self-wakes were not being detected and displayed in the console. The
`burn` task in the `app` example - which deliberately has many
self-wakes - was not registering any.

It appears that a logic error was present in the self-wake counting in
`console-subscriber` since it was added in #238. When a self wake was
detected, the `wakes` count was incremented a second time (the `wakes`
count is incremented for all wakes before checking for a self wake),
instead of increamenting the `self_wakes` count.

This PR fixes the logic so that when a self wake is detected, the
`self_wakes` count is incremented.

Each view in tokio-console has a widget up the top that lists the
available controls for that view. There was a common implementation of
this for table based views (tasks, resources, and async_ops) and
separate implementations for the task and resource views. The resource
view included two controls widgets, one for the Resource details at the
top of the view, and another above the table of Async Ops at the bottom
of the view.

This change centralises the logic for the creation of this controls
widget. This change is mostly a precursor to also displaying the
controls in the help view (at which point we can revisit whether the
entire list needs to be shown at the top of the screen).

Controls (an action and the key or keys used to invoke it) are defined
in structs so that their definition can be separated from the display
logic (which includes whether or not UTF-8 is supported).

This allows the problem of the text in the controls widget wrapping in
the middle of a control definition to be fixed. Previously a subset of
the controls would have wrapped like this:

```text
controls: select column (sort) = ←→ or h, l, scroll = ↑↓ or k, j, view details
= ↵, invert sort (highest/lowest) = i,
```

Notice how "view details = ↵," was split across multiple lines. The same
list of controls will now wrap at a full control definition.

```text
controls: select column (sort) = ←→ or h, l, scroll = ↑↓ or k, j,
view details = ↵, invert sort (highest/lowest) = i,
```

Additionally, the list of controls on the Resource view has been
consolidated up the top of the screen.

Universal controls, those that are available in all views, are also
defined centrally. As well as the quit action, using the space bar to
pause has been added to that list. This was previously somewhat of an
undocumented feature.

We often receive questions about the meaning of certain columns in the
different views in Tokio Console.

This change adds additional documentation to the `tokio-console` README
- which is also used in the docs.rs main page - describing each column
in the tasks, resources, and async ops tables. Where there are a fixed
set of values possible in the column, those values are also described.

Additionally, the 4 views are enumerated and separated into sections to
aid readability and allow deep linking.

Co-authored-by: Eliza Weisman <[email protected]>

* fix(console): remove trailing space from task/resource location

When a file location is formatted, an extra space is added at the end.
This appears to be the result of some refactoring from a case where we
needed the extra space at the end.

Currently, the extra space results in there being 2 spaces between the
Location column and the Fields column in the tasks list view, and the
same between the Location column and the Attributes column in the
resources list view.

It is also causing issues when attempting to truncate the first part of
the location in #441 (during which this extra space was discovered).

This change removes the trailing space.

When entering and exiting a span the old code was also updating the parent
stats. This was causing excessive polling being reported for the parent tasks.
See issue #378 for more details. The regression was introduced by the refactor
in #238.
This fixes the issue by limiting updates to the current span.

Closes #378

Co-authored-by: Hayden Stainsby <[email protected]>
Co-authored-by: Eliza Weisman <[email protected]>

This closes #411.

This is how it looks like.

<img width="514" alt="Screenshot 2023-07-03 at 12 22 24 PM" src="https://github.com/tokio-rs/console/assets/41150432/878a43e6-1512-49c0-85fd-0e245cc6ee04">

Co-authored-by: Hayden Stainsby <[email protected]>

This appears to be breaking it.

Signed-off-by: Eliza Weisman <[email protected]>

Signed-off-by: Eliza Weisman <[email protected]>

This PR adds an explicit dependency to futures-core for `console-api` to
fix broken builds. Without this fix I get the following errors:

```
error[E0433]: failed to resolve: use of undeclared crate or module `futures_core`
   --> /home/weiznich/.cargo/registry/src/index.crates.io-6f17d22bba15001f/console-api-0.5.0/src/generated/rs.tokio.console.instrument.rs:275:34
    |
275 |         type WatchUpdatesStream: futures_core::Stream<
    |                                  ^^^^^^^^^^^^ use of undeclared crate or module `futures_core`

error[E0433]: failed to resolve: use of undeclared crate or module `futures_core`
   --> /home/weiznich/.cargo/registry/src/index.crates.io-6f17d22bba15001f/console-api-0.5.0/src/generated/rs.tokio.console.instrument.rs:289:38
    |
289 |         type WatchTaskDetailsStream: futures_core::Stream<
    |                                      ^^^^^^^^^^^^ use of undeclared crate or module `futures_core`

error[E0433]: failed to resolve: use of undeclared crate or module `futures_core`
   --> /home/weiznich/.cargo/registry/src/index.crates.io-6f17d22bba15001f/console-api-0.5.0/src/generated/rs.tokio.console.trace.rs:212:27
    |
212 |         type WatchStream: futures_core::Stream<
    |                           ^^^^^^^^^^^^ use of undeclared crate or module `futures_core`

```

The somewhat funny thing is that only happened after I've updated some
unrelated dependencies. It worked before, but after looking at the
relevant code I'm really surprised that it ever compiled without error.

The `ConsoleLayer` builder provides the user with a console layer and
a server, which is used to start the gRPC server.

However, it may be desireable to expose the instrumentation server together
with other services on the same Tonic router. This was requested
explicitly in #449 428.

Additionally, to add tests which make use of the instrumentation server
(as part of improving test coverage for #450), more flexibility is
needed than what is provided by the current API. Specifically we would
like to connect a client and server via an in memory channel, rather
than a TCP connection.

This change adds an additional method to `console_subscriber::Server`
called `into_parts` which allows the user to access the
`InstrumentServer` directly. The `Aggregator` is also returned and
must be set to run for at least as long as the instrument server. This
allows the aggregator to be spawned wherever the user wishes.

To facilitate the addition of functionality which would result in more
"parts" in the future, `into_parts` returns a non-exhaustive struct,
rather than a tuple of parts.

Closes: #428

…449)

Now it is possible while navigate in `async_ops_table` to go directly to
details of the task that you are pointing on the list.

This closes #448

The current logic present in `IdData::drop_closed` marks an item (task,
resource, and async op stats) to be dropped in the case that the item
**is** dirty and there **are** watchers: `(dirty && has_watchers)`.

This causes a case where if an item is first received and then completes
in between the aggregator push cycle, it will be discarded immediately
and never sent.

This logic has been in place since the concepts of watchers and dirty
items was introduced in #77. However since an item that is created and
then dropped within a single update cycle isn't likely to be missed in
the UI, it may never have been noticed.

Instead the logic should be to **retain** an item if **any** of the
following is true:
* there are watchers and the item is dirty: `(dirty && has_watchers)`
* item has been dropped less time than the retention period:
  `dropped_for <= retention`.

I just came across this typo in the Readme when using `tokio-console` for the first time. 
This is a great tool 👍

…Id (#455)

In #403, the tasks list view was changed to display the `tokio::task::Id` of
the task, instead of the tokio-console generated display ID (which isn't
stable across restarts of the tokio-console itself. However, the task
detail view wasn't updated and was still using the display ID.

This change fixes the ID displayed in the task detail view so that it also
displays the `tokio::task::Id` of the task.

Clippy was complaining about 3 new things in 1.72.0. Two new lints and
one updated one.

When `futures-core` was added as an explicit dependency on `console-api`
in #453, it was only added to the `console-api` Cargo.toml file. It
wasn't added to the Cargo.lock file shared by the workspace.

Since Rust 1.72.0, Cargo is adding this dependency to Cargo.lock
locally, so it makes sense to check in that change.

Add cfg `console_without_tokio_unstable` for developers to turn off the
assertion on `tokio_unstable`. This is useful for non-tokio runtimes
which has `tokio-console` support.

I noticed that `console-subscriber` was my only dependency pulling in
the `futures` top-level library so I decided to try my hand at removing
that dependency. This still relies on `futures-task` for an optimized
`NoopWaker`

Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.21.0 to 1.24.2.
- [Release notes](https://github.com/tokio-rs/tokio/releases)
- [Commits](https://github.com/tokio-rs/tokio/commits)

---
updated-dependencies:
- dependency-name: tokio
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>