[META] Remove drupal_set_message()

My original hope was to use Symfony Flash messages on the request, as they were beefed up to be feature-parity with drupal_set_message() back in Symfony 2.1 at our request. That however has been effectively blocked on #1858196: [meta] Leverage Symfony Session components for closing in on 2 years. :-/ (I think at the moment the remaining issues are testbot issues, not code issues, so I don't know how to fix those.)

@Crell that's not very relevant to the parent issue.

Both drupal_set_message() and Symfony flash messages use the $_SESSION to store messages. Last time I looked I was unable to find an implementation for collection and display of flash messages in Symfony 2.

It's the collection and display of messages that can cause problems if you have messages set in AJAX or ESI requests since they might complete after the 'main' request, or there might not be a 'main' request in PHP at all.

Session storage is by definition global so it's not the same problem as CSS/JS assets, the page title etc where that information would just get lost, the worst that happens at the moment is that a message gets shown on the next request instead of the current one.

@xjm yes just collecting the messages via yet another request (which checks and clears out $_SESSION) would work fine for this, I'm not we want to do that in core though, rather make sure it's doable from contrib.

With #2068471: Normalize Controller/View-listener behavior with a Page object, we'd be clearly splitting the body from the html rendering. One thing that may let us do is push messages into JS settings, because we're certain that the page has been reduced to a string by that point so any processing involved in that has happened already. Then on render, pull them out of there and render client-side into a known div ID in the page.

Then it's natural for Ajax cases to just turn any pending messages into more Ajax commands, which can get rendered in the same way.

Downside: this requires JS for any messages to be displayed. Pages without messages wouldn't need JS, but we'd need at least a little for messages to work. I don't know of an alternative there. (And I am not convinced that's a show-stopper in 2014.)

I just opened #2278383: Create an injectible service for drupal_set_message(), which may or may not address some of your concerns.

As a normal task, per #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?, I think this should be postponed to 8.1.x. Merely improving testability is not a good enough reason to get this included this late in the release cycle. However, if #2073817: [META] Remove drupal_set_message() identifies an important cacheability/performance bug that requires this to be done, then we can move it back to the 8.0.x queue.

Dries wrote #9 while on a call with me, so I happen to know that he intended it for #2278383: Create an injectible service for drupal_set_message(), so reverting issue attributes of this meta issue.

Though based on the comment, this issue will also get postponed to 8.1.x unless a major bug requires it to be done. But moving it back to the 8.0.x queue for now, to allow for some discussion on whether such a bug exists.

I am triaging the issue as a part of DrupalCon NOLA.
drupal_set_message() still exists in the code, and is widely used, so the issue still present.
As a part of the solution, should drupal_set_message() be removed as deprecated in 8.x, its usage removed, and function itself be removed before 9.0.0?

Postponed on #2278383: Create an injectible service for drupal_set_message() at this point. At the moment there's nothing to deprecate it for.

System messages are stored in a Symfony Flashbag, so there is no need to hack session variables, which can change from version to version. In Drupal 8.5 a new Messenger service was introduced to encapsulate the symfony flash bag and you can delete messages with deleteAll():

\Drupal::messenger()->deleteAll();