Align status transitions, events and required access rights when saving

Description

Align status transitions and events happening when saving content so that they are consistent. The changes should be made based on the following principles.

Status

• SaveAction.Default replaces SaveAction.None
• (New) SaveAction.CheckOut should be used to check out the current content version.
• All status changes should have a primary SaveAction. A new Schedule (DelayedPublish) action is required
• Saving an item, regardless of SaveAction should update the current version, except when status is Published or PreviouslyPublished, in which case a new version is created.
• No status changes are allowed on the current version if status is Published or PreviouslyPublished.
• When ForceCurrentVersion is used on a Published or PrevioslyPublished version, it must be on its own (Default) or paired with the Publish action in case of Published content.
• Saving a content item without version should be identical to saving the version that is actually loaded.
• SaveAction.Publish (or Default) should be the only action allowed on Unversioned content
• Invalid SaveAction combinations should throw an InvalidOperationException
  • Using ForceCurrentVersion or ForceNewVersion on a new version should be invalid
  • Using ForceNewVersion on unversioned content should be invalid
  • Using both ForceCurrentVersion or ForceNewVersion should be invalid
  • Using (deprecated) DelayedPublish with any other action than CheckIn should be invalid

Required Access

• Create access is required if no previous version exists
• Create access is required when saving a new language branch
• Edit access is required to update content, e.g. content is modified
• Edit access is required to CheckIn or CheckOut (or StartReview) a version
• Publish access is required to Publish or Schedule a version or update a Published or DelayPublished version
• Edit access is required to Reject a version
• Overloads without AccessRights should pass on AccessRights.Undefined to implementing method.

Events

• Save events should always be raised when Save is called
• Status transition information should be included with the event arguments
• Publish events should (still) be raised when a content item is published.
• New events Checking/CheckedOutContent, Scheduling/ScheduledContent, Creating/CreatedLanguageBranch

Breaking Changes

• Saving unpublished content that was loaded without version now has the same behavior as when this content was loaded with a version. The previous behavior was to automatically create a new version.
• The behavior when saving a checked-in version was previously dependent on if the content was modified or not. This is no longer the case, and new versions are only created if the save action used is Save. Other actions update the current version. It's still possible to control the version behavior using the ForceCurrentVersion or ForceNewVersion flags.
• It is no longer possible to change the status of a previously published version without creating a new version. Calling save with the ForceCurrentVersion flag throws an exception unless paired with SaveAction.Default.
• Calling Save with an invalid SaveAction now results in an ArgumentException before any events are raised, rather than an EPiServerException after initial events have been raised.
• Saving a content item with the ForceNewVersion flag throws an ArgumentException.
• Saving unversioned content with any other (primary) action than Publish or Default throws an ArgumentException.
• Saving unversioned content with the ForceNewVersion flag throws an ArgumentException.
• Using SaveAction.DelayedPublish without combining it with SaveAction.CheckIn throws an ArgumentException
• Combining SaveAction.ForceNewVersion with SaveAction.ForceCurrentVersion throws an ArgumentException
• Save events are always raised when the Save method is called.
• Status event is always raised even if the status won't change, e.g. CheckingIn is raised when Save is called even if the status already is CheckedIn.
• The EPiServer.Core.Internal.StatusTransition class is moved to the EPiServer.Core namespace
• Creating new language branches of unversioned content now checks that Provider has Create capabilities and not just Edit.
• IContentRepository Save extensions methods without a required access parameter pass AccessLevel.Undefined to the Save method on the repository rather than trying to resolve the required access right.
• The access rights validation in the Save method respect changes made to the required access by any event handler run before the Save is completed, e.g. Creating, Saving, Publishing, etc.
• The default required access right for delay publish content is Publish rather than Edit.
• The default required access right to reject content is Edit rather than Publish.
• StartPublish must be set when content item is set for scheduled publishing