Remove hal.module BC layers

Do we still want to keep HAL around after JSON:API is included in core? I vote for removal from D9.

#4 @jibran I agree! Can you help me push #3049856: [policy] Mark HAL module as deprecated in D9 so it can be removed in D10 forward.

Note: Should also remove all left-over references to hal_update_8501() and possibly others.

Patch from #3 didn't apply anymore, created a new one from scratch after applying patch from #2893804-91: Remove rest.module BC layers .

+++ /dev/null
@@ -1,96 +0,0 @@
-   *
-   * @deprecated in drupal:8.5.0 and is removed from drupal:9.0.0.
-   */
-  public function normalize($entity, $format = NULL, array $context = []) {
-    $data = parent::normalize($entity, $format, $context);
-
-    $this->addCacheableDependency($context, $this->halSettings);
-
-    if ($this->halSettings->get('bc_file_uri_as_url_normalizer')) {
-      // Replace the file url with a full url for the file.
-      $data['uri'][0]['value'] = $this->getEntityUri($entity);
-      @trigger_error("Replacing the file uri with the URL is deprecated in drupal:8.8.0 and is removed from drupal:9.0.0. Use the provided url property instead and disable hal.settings:bc_file_uri_as_url_normalizer. See https://www.drupal.org/node/2925783", E_USER_DEPRECATED);
-    }
-
-    return $data;
-  }
-
-  /**
-   * {@inheritdoc}
-   */
-  protected function getEntityUri(EntityInterface $entity, array $context = []) {
-    assert($entity instanceof FileInterface);

this class is not deprecated anymore, we can't remove it, only the first method that is marked as deprecated.

What we do need is remove this configuration, the schema for it and add an update function that removes it on existing sites. Basically the same dance as in the rest issue.

Leaving at postponed as we'll likely need to reuse the fixture we have in the rest issue and it will be easier to do that once that is committed.

Yes, failing as expected :)

Tagging as a requirement for Drupal 9.0-beta1.

Reroll solving #14 and #19. However not sure should we extend rest-module-installed.php fixture or not. Created a separate hal-module-installed.php fixture.

Working on this.

So I learned something interesting while working on #3095333: Extend filled database dump with new stable modules and content for them, and that is that the filled dump already has hal+serialization+rest enabled, so we don't actually need to fake anything here, we just need to use the filled dumps. That does make the test quite a bit slower, but it also means fewer fixtures and workarounds to maintain.

I updated HalSettingsDeletionUpdateTest to use that, and it passes now. Maybe better to do the same with the rest test in a separate issue? That said, the test actually still tested the rest config *and* we removed too much here, we still need the link domain setting, so this update must only remove the specific key. Cleaned that up.

Other fixes include removing the cache tag where it is no longer needed and re-adding the file entity normalizer service. Also still quite a few tests covering removed functionality, that was deprecated a long time ago, so some of these are a bit tricky, like removing array keys in return values. But, this has also been done very long ago and is unlikely to be used.

interdiff is weird in a few places due to re-adding removed files and then removing parts.

One thing: the update test passes now without @group legacy as well, I'm not sure if we should keep that or not, as right now it makes sense to not have it to make sure we have no deprecations left, but sooner or later, we'll add a system.module update or so that will trigger one and then all tests would need to be updated.

I kept it here but removed in the hal issue IIRC, sorry about the inconsistency :p

Note: The tests failed because I removed the @group legacy from that test and now it has none left.

So, per https://drupal.slack.com/archives/C1BMUQ9U6/p1580561124478000, we should add that back *and* also make sure we have a @group hal there and then it should run the tests.

Won't have time for that during the day.

No volunteers it seems :)

This should fix the remaining media tests.

Although, I do wonder whether not all hal+json resources should always still include config:hal.settings cache taq anyway because the logic in \Drupal\hal\LinkManager\LinkManagerBase::getLinkDomain() depends on it, seems like a classic cacheability-only-added-in-positive-case bug. But that's not really related and should be fixed in a separate issue.

Committed 8c2f0de and pushed to 9.0.x. Thanks!