Provide a route provider for add-form of entities

Since there hasn't been much progress here taking the liberty of postponing on #2651716: Entity::getEntityFromRouteMatch() should support bundles which would alleviate the need for a dedicated controller method here for the add route.

Of course if someone wants to work on this for now we could always remove/deprecate the add controller again, so if you object feel free to re-open.

Still postponed, but started some work on this. We should really get this done for 8.1. It's certainly not the last piece of the "Entity API out of the box experience"-puzzle but I still think it's a big one. With this we have full UI crud out of the box. Even if e.g. the default list controller is not really great, it's at least something you can work with to get started quickly.

So far only implemented the add-form. See @bojanz's http://cgit.drupalcode.org/entity/tree/src/Routing/CreateHtmlRouteProvid... for prior art. I started with that but tried to align this as close as possible with the existing routes. I also tried this out for nodes and taxonomy terms (although this is not in the patch) to validate that it actually serves core use-cases. In the end I ended up with a fair amount of increased complexity in contrast to contrib Entity API, but not sure how to improve that without losing actual functionality. Would love some feedback on that, especially of course from @bojanz, but also from everyone else :-) The one thing where I did somewhat deviate from the Entity API implementation is that instead of checking for bundles in the title controller itself I provided two different title controllers depending on whether the entity type supports bundles. I personally find that a bit more elegant, but - as everything else - this is of course up to debate.

And as mentioned above this builds on #2651716: Entity::getEntityFromRouteMatch() should support bundles to be able to use _entity_form directly. Thus, a for-review and a for-bot patch is provided.

Will tackle the list route now, where I hopefully end up with less complexity.

And needs tests, as always.

So trying to implement the list controller generically, I realized that it's not really possible without #1850080: Entity type labels lack plurality, cannot generate UI text based on label if plural is needed. I.e. we cannot properly generate a title for the collection route without that. So I would propose splitting the two routes into two issues, so we can hopefully make progress independently.

Let's see. This should fix some tests and also adds unit tests.

So rescoping the issue title per the above. I think this is pretty much ready. I couldn't help myself from fixing a few minor, unrelated things along the way. Of course feel free to complain about those and I'll take them out.

From looking at the code, this looks like a step in the right direction of a full out-of-the-box experience for the Entity API. I always thought it sucked that every entity providing module had to look at Node to find a way to do an add_form route.

Thank you for picking this up, tstoeckler!
I've reviewed the patch and it looks good. I like the additional details such as adding validation for the entity type id param.

One thing I've noticed we've lost in the title logic reshuffle is "Use entity type instead of bundle in the add label, if there's only one bundle" ("Add product" instead of "Add default", where "default" is bundle). I figured it's a nice touch for entity types that can have multiple bundles, but the majority use case is to use only one bundle.
A thing to discuss, at least.

Nitpick:

+          // If the bundles are not entities, the bundle key is used as the
+          // route parameter name directly.
+          $route
+            // See above.
+            ->setDefault('bundle_parameter', $bundle_key)
+            ->setRequirement('_entity_create_access', "{$entity_type_id}:{$bundle_key}");

"// See above." is redundant, no?

Thanks for the review. Yes, the "See above" is bogus.

One thing I've noticed we've lost in the title logic reshuffle is "Use entity type instead of bundle in the add label, if there's only one bundle" ("Add product" instead of "Add default", where "default" is bundle). I figured it's a nice touch for entity types that can have multiple bundles, but the majority use case is to use only one bundle.
A thing to discuss, at least.

Ahh, thanks for mentioning that. I had seen that but had assumed that was for the case where we create a bogus bundle for entities that generally don't have bundles, i.e. the "User" bundle of the "User" entity type. In that case it's not needed to use the bundle so I dropped it...

... but your use-case totally makes sense, I did not consider that. i agree that we should bring that back.

Here we go.

Addressed #17.

I was a bit sloppy.

Sigh.

#2651716: Entity::getEntityFromRouteMatch() should support bundles just landed, so this will need a re-roll.

Rebased.

Ahh yes, the admin route is still needed, but we should be able to remove the add_form route with the patch.

The "needs work" in #28 seems accidental, or I'm missing something?

This looks ready to go from my side. And dawehner already gave his +1 in #18

+++ b/core/lib/Drupal/Core/Entity/Routing/DefaultHtmlRouteProvider.php
@@ -80,6 +98,78 @@ public function getRoutes(EntityTypeInterface $entity_type) {
+            $route->setRequirement($entity_type_id, '\d+');

Woo, will be good to see this gone from the routing yaml eventually.

This looks great and I couldn't find anything to complain about. So committed/pushed to 8.1.x, thanks!

Would be good to open a follow-up to convert core entities to use this - I'm sure people are copying those still as examples.

Worth a release notes mention.

This issue is missing a change record. (We should add change records for noteworthy API additions.) It can be combined with the CR for #2666792: Provide a route provider for add-page of entities.

Follow-up: #2767853: Provide a route for collections of entities