fix(methods): remove management plane, require strong consistency

[toumorokoshi]

The introduction of the concept of management plane and data plane and it's subjective definition in the AEPs was leading to ambiguous guidance. Removing the mention of those concepts until a clearer criteria can be established.

This change requires that a decision must be made for strong consistency. As operations that are not strongly consistent can result in manual per-resource patches for declarative clients, require strong consistency for all standard methods.

🍱 Types of changes

What types of changes does your code introduce to AEP? Put an x in the boxes
that apply

• Enhancement
• New proposal
• Migrated from google.aip.dev
• Chore / Quick Fix

📋 Your checklist for this pull request

Please review the AEP Style and Guidance for
contributing to this repository.

General

• Basic Guidance is met.
• Ensure that your PR
  references AEPs
  correctly.
• My code has been formatted
  (usually prettier -w .)

[wora]

Can we break down this PR so we can discuss one thing at a time?

[rofrankel]

If an organization doesn't have the right infra to provide strongly consistent CRUD methods, does that mean the organization can't be AEP-compliant?

[toumorokoshi]

If an organization doesn't have the right infra to provide strongly consistent CRUD methods, does that mean the organization can't be AEP-compliant?

It certainly makes the declarative clients inconsistent, and in turn buggy and often require some client-side custom logic to work around it.

There is an argument that declarative clients aren't necessary for some use cases - but I feel this kind of case could be argued for multiple parts of the AEPs. Every must will result in omitting some set of the APIs out there.