ContentEntityBase::createDuplicate() should reset default revision flag

Oh, even weirder. The test already does save multiple times, but only tests with a base field. The bug that we see with paragraphs happens only with configurable fields, because dedicated table *reads* are different.

Drupal reads base fields also from the revision table too, and since that is updated, the test is happy. But if actually check the database, you can see that the base table has _not_ been updated in that test.

I made the test more explicit by checking the new/default revision flags explicitly and also doing an entity query to check the base table values.

I wonder if we can somehow detect if you attempt to save the default revision as not-the-default revision and throw an exception then or something because that is not a valid thing to do.

> I am not following the second sentence. That a new entity, once saved is no longer the default revision? Then what is the default revision for a newly saved entity?

That's the point, there is no default revision anymore the in the loaded entity object.

The override that it is the default revision is transient and goes away as soon as it's saved:

  public function isDefaultRevision($new_value = NULL) {
    $return = $this->isDefaultRevision;
    if (isset($new_value)) {
      $this->isDefaultRevision = (bool) $new_value;
    }
    // New entities should always ensure at least one default revision exists,
    // creating an entity without a default revision is an invalid state.
    return $this->isNew() || $return;
  }

So if it's unsaved, it's always default, but as soon as isNew() returns FALSE, it suddenly might no longer be, and if you save it again, you end up with an invalid state.

> I wonder if we can somehow detect if you attempt to save the default revision as not-the-default revision and throw an exception then or something because that is not a valid thing to do.

good thinking, past-me! current-me discovered this again and opened an issue for it: #3499181: Disallow saving the current default revision as a non-default revision. This is blocking that now.

This was RTBC and somehow fell off the bandwagon, lets try to finalize it. Still applies, not sure why it was needs work, random fail maybe?

Merge request is green and identical to the patch that was RTBC.

Not sure if we want to keep the explicit test coverage with the direct query, as with the issue that this is blocking, saving would result in an exception instead, we're kind of testing that issue, not this.