Deprecate diff chain features

[cycraig]

Description of change

Deprecates all diff chain features, structs, and functions. This is mostly achieved by deprecating the identity-diff crate and entire diff modules where possible, which marks all imports from those paths as deprecated.

Note that, as discussed, this also forces all Account updates to publish to the integration chain to prevent a migration step for the majority of users.

The diff_chain example has been removed along with the diff updates in resolve_history to discourage their use but the documentation/wiki retains references to the diff chain, along with unit tests, in case we choose un-deprecate the feature in the future.

Rust

In Rust the deprecation annotations cause compilation warnings (which we ignore internally with #![allow(deprecated)]).

#[deprecated(since = "0.5.0", note = "diff chain features are slated for removal")]
pub fn diff<'query, 's: 'query, Q>(

warning: use of deprecated struct `identity::iota_core::DiffMessage`: diff chain features are slated for removal
  --> examples\low-level-api/create_did.rs:33:13
   |
33 |   let diff: DiffMessage = document.diff(
   |             ^^^^^^^^^^^

warning: use of deprecated associated function `identity::iota_core::IotaDocument::diff`: diff chain features are slated for removal
  --> examples\low-level-api\create_did.rs:33:36
   |
33 |   let diff: DiffMessage = document.diff(
   |                                    ^^^^                              ^^^^

warning: use of deprecated associated function `identity::iota::Client::publish_diff`: diff chain features are slated for removal
  --> examples\low-level-api\create_did.rs:39:18
   |
39 |   let _ = client.publish_diff(receipt.message_id(), &diff).await?;

and deprecated functions are underlined:

Javascript

In Javascript the @deprecated doc-comment causes the IDE to strikethrough the function. I'm not aware of any compilation warning for Typescript though, unless it can be enabled with a lint? Is there anything more we should do here?

/// @deprecated since 0.5.0, diff chain features are slated for removal.
#[wasm_bindgen]
pub fn diff(

Links to any relevant issues

Fixes #703.

Type of change

• Chore/bug fix (a non-breaking change which fixes an issue)
• Enhancement (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Fix

How the change has been tested

Tests and examples pass locally.

Change checklist

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[PhilippGackstatter]

Shouldn't this just be removed? If the account always publishes integration updates, then this flag becomes useless. Compared to 0.4 this wouldn't even be breaking, because we added PublishOptions after that release.
Raises the question whether our Breaking Change label is relative to the previous release or relative to the last "proper" release (0.4 in this case). Would be weird actually, to add a method that is deprecated from the start.

As far as I can see only the test_account_publish_options_force_integration would have to be removed, so it shouldn't have to many compounding effects.

[cycraig]

The force_integration_update still has the effect of force-publishing even if there are no changes, so I'm unsure if we should remove it entirely or replace it with something like force_publish. The point is that because it was decided not to remove the diff chain (yet), there is the chance that all these features will be un-deprecated, which would make force_integration_update immediately useful again as it currently stands.

Breaking change is relative to the last non-dev release.

[PhilippGackstatter]

Since we might re-enable diff chain features, which might make force_integration_update useful again, I'll approve 👍.

[eike-hass]

LGTM! The JSDoc comment is the way to go.