[policy] Mark HAL module as deprecated in D9 so it can be removed in D10

I've at least two contrib modules relying on hal - default_content and entity_pilot

I'd be happy to step up as maintainer if that's the primary removal reason

It is not just the maintainer issue. After adding JSON:API to core, the functionality HAL provides is almost the duplicate. The contrib modules require HAL can simply require drupal/hal using composer and will continue to work in D9.

@mixologic has a core module usage breakdown snapshot from a few months back. I don't remember HAL usage from there, but it would be nice to see. The data is being reported to d.o by those sites using update module at least, which would be indicative of relative use (definitely not as absolute numbers), assuming we want to derive supporting data based on sites using update.module.

I don't think that should be the only condition of decision, but it could help inform the decision.

Too late for D8.8, but I think moving it to contrib makes sense.

There are various issues that are very hard to resolve, see for example #2925520: Add a computed 'file_url' property to FileItem (for exposing file URL in file field normalization).

I'm also still relying on this through the default_content module, but hal+json became IMHO less and less convenient for that use case as core tried to make it more useful for REST, by adding more data, formatted representations, computed fields, formatted dates.. all things that are just in the way for how default_content uses it.

I've some thoughts on adding a custom serialization format to default_content that still covers what it needs (relationships, specifically but also things that are hard right now like files) while keeping it as close as possible to the raw data structure. There's also yaml_content as an alternative, but it's only alpha and has very few usages compared to default_content.

Tagging.

Moving this to the Ideas queue for discussion there. (We separate the policy discussion from implementation for these since there are different needs.)

The lack of maintainership is a problem. I agree the duplication of functionality is not useful either. Also JSON:API by this time has a much larger ecosystem of modules around it compared to HAL I believe. That said, #3158669: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version indicates 12.5% use of HAL among reporting sites at the time. Given all of the above I would still lead to deprecate in Drupal 9 with removal for Drupal 10.

Parenting to the right Drupal 10 meta. Removing product signoff tag, since I provided that in #16.

We are a bit blocked on implementation with #3135100: [policy and meta] Provide a proper mechanism for deprecating modules and themes, but in terms of the overall decision, untagging for release manager review.

Now that the lifecycle key has been added to .info.yml we're no longer blocked on implementation. Is anything more needed before we can go ahead with this one?

Marking this RTBC, I've also unpostponed #3049857: Remove HAL module from core and create a contrib project for it.

There's nothing ce contrib instead of it
https://www.drupal.org/project/jsld

This is done now