Update direction attribute transition schedule on READMEs

[mwear]

Description:
This work is to support the effort of transitioning from emitting network metrics with a direction attribute, to emitting different metrics based on the direction. Our transition plan is largely the same, but we want to roll out all the changes in a single release. To do that, we need to implement the necessary feature gates in each receiver, after which, we will publish a revised transition schedule. We discussed potentially removing the feature gate documentation itself here, but I have left the documentation as-is since the gates are technically usable. Let me know if anyone feels strongly that we should remove it as well, and I can do so as part of this PR. Based on feedback I've left the transition plan largely unchanged. What has changed is that the uncertain future dates and releases have been replaced with TBD, to be filled when when we've firmed up our plans.

Link to tracking Issue:
#11815 and comment: #11815 (comment)

[TylerHelmuth]

I like the updated transition plan laid out on the issue, but I'd rather see these existing plans updated to reflect the new plan instead of outright removed.

The reason I'm against removing these completely is that people have already had the opportunity to share these docs. I think it would be a bad experience for those already aware of the feature gates/metric changes to show up to this readme and not be able to find that information anymore.

I would prefer to see the section headers stay the same (so the links still work) and then the content be updated to reflect the new plan. If all the new section includes is an update to the issue's plan then I think that would be sufficient in the meantime

[mwear]

I like the updated transition plan laid out on the issue, but I'd rather see these existing plans updated to reflect the new plan instead of outright removed.

That's fair. The transition plan is largely unchanged. What has changed is the exact versions and dates for the last two phases of the plan. I think the most important thing is that Phases 2 and 3 happen in lock step once the feature gates have been introduced. Perhaps we can list the steps of the transition plan, where phase 1 will have the release dates and version where the feature gates are/were introduced and phases 2 and 3 can be listed as TBD, which we can fill in when we have finalized the plan?

For example, something like:

##### Transition schedule:

1. Phase 1, v0.56.0, July 2022:

- The new metrics are available for all scrapers, but disabled by default, they can be enabled with the feature gates.
- The old metrics with `direction` attribute are deprecated with a warning.
- `receiver.memcachedreceiver.emitMetricsWithDirectionAttribute` is enabled by default.
- `receiver.memcachedreceiver.emitMetricsWithoutDirectionAttribute` is disabled by default.

2. Phase 2, date and version TBD:

- The new metrics are enabled by default, deprecated metrics disabled, they can be enabled with the feature gates.
- `receiver.memcachedreceiver.emitMetricsWithDirectionAttribute` is disabled by default.
- `receiver.memcachedreceiver.emitMetricsWithoutDirectionAttribute` is enabled by default.

3. Phase 3, date and version TBD

- The feature gates are removed.
- The new metrics without `direction` attribute are always emitted.
- The deprecated metrics with `direction` attribute are no longer available.

[TylerHelmuth]

@mwear Ya I like that. Linking to the tracking issue somewhere would also be good.

[mwear]

I updated the transition plan with TDB in place of the versions and dates that are questionable. I also updated the verbiage around warnings for some receivers. The warnings were removed from the hostmetrics receiver and never added back. To my knowledge they were never released. The memcached readme incorrectly stated that deprecation warnings would be logged, so I just removed the incorrect statement. Zookeeper actually does log deprecation warnings, so I've left the messaging as-is. We can change it if we update the receiver itself.

[TylerHelmuth]

Thanks @mwear!

[mwear]

I suspect a changelog is not needed for this PR? If I'm wrong, please let me know.

[bogdandrutu]

I think we should stop releasing this unreleased spec change.

[dmitryax]

@bogdandrutu this change is just for documentation. Currently the docs provide misleading transition schedule based on version numbers, some of them even passed. I suggest removing the transition schedule until open-telemetry/opentelemetry-specification#2726 is resolved

cc @mwear @TylerHelmuth

[bogdandrutu]

@dmitryax I am unblocking this, and make you responsible to delete or correctly update the schedule until specs are released.

Dmitrii is responsible for this now :)

[dmitryax]

Ok, I submitted another PR to update the docs #13436

[dmitryax]

Replaced by #13436