MONGOID-5228 disallow _id to be updated on persisted documents

[jamis]

Previously, updating _id on any document (top-level or embedded) would behave inconsistently. In some cases, the _id would be ignored, and the other updates would proceed. In another case, the entire update would be ignored. And in yet other cases, the update would succeed.

The specific cases were:

• Updating the _id of a top-level document via either #save or #update: the new _id was ignored, and the rest of the update (if any) succeeded.
• Updating the _id of an embedded document (either #embeds_one or #embeds_many) via #save or #update: the new _id was accepted and persisted to the database.
• Updating the _id of an embedded document (#embeds_one) via an update to the parent (e.g. parent.update(child: { _id: ... })): the entire update to the child was ignored, including both the _id field and any other attributes being updated.

This change makes it so that _id is explicitly made immutable once a document has been persisted. The same behavior is intentionally enforced regardless of whether the document is embedded or not. If you find yourself needing to update the _id field in an embedded document, you'll need to use the lower-level driver methods to accomplish this. We believe modifying the _id field (even in embedded documents) is an anti-pattern.

For legacy purposes, if you have an app that currently relies on updating the _id field of embedded documents, a new feature flag has been introduced:

Mongoid::Config.immutable_ids = true

The default is true, which enforces the immutability of the _id field on all documents. Setting this feature flag to false will restore the legacy behavior (as described above).

[johnnyshields]

This seems reasonable. I've never encountered a use case to change the _id of a persisted doc, embedded or otherwise.

[comandeo]

I agree with the changes, very well done.
However, I believe the changes are breaking; therefore, we should reflect them in the changelog, and probably hide behind a feature flag. I can imagine these changes may break some apps.

[comandeo]

ReadonlyAttribute error message contains the following wordings:

summary: "Attributes flagged as readonly via Model.attr_readonly
  can only have values set when the document is a new record."
resolution: "Don't define '%{name}' as readonly, or do not attempt
  to update its value after the document is persisted."

This is misleading in case of _id field, since it is not explicitly flagged as readonly. I suggest raising a dedicated error here.

[jamis]

Yeah, good point. I've updated the PR with a new ImmutableAttribute exception.

[johnnyshields]

Maybe rename to check_for_id_mutation! or check_for_id_change!? "Violation" in this context sounds like a malformed (i.e. non-BSON) ID. Similar with acceptable_id ID below.

[johnnyshields]

@jamis looks like tests are broken on master. See failing Github Actions runs in this PR. Raised https://jira.mongodb.org/browse/MONGOID-5565 to track.