fix(admin) proper support for PUT /{entities}/{entity}/plugins/{plugin}

[thibaultcha]

Prior to this patch, PUT requests to plugins under their associated
resources (e.g. /services/{service}/plugins/{plugin}) would
systematically return 404, instead of creating the plugin if it did
not exist. This was because the before Lapis hook attempts to retrieve
the plugin in the database before modifying it. Those endpoints are
preserved for backwards-compatibility purposes (being too nested to be
auto-generated), so that workaround is fine.

This patch ensures that we skip this logic with PUT requests, plus
makes sure that we set the self.args.post arguments according to the
self.params arguments (path segments with foreign UUIDs).

Thanks @gszr for the report.

[thibaultcha]

@gszr Will you make sure this works on your side? Thanks!

[bungle]

. Those endpoints are preserved for backwards-compatibility purposes (being too nested to be auto-generated), so that workaround is fine

I think we might want to make this also autogenerated for all the entities. Let me explain:

• /services/{service}/plugins/

This is the level where autogenerator stops. Now this:

• /services/{service}/plugins/{plugin}

Is not autogenerated but extended. I think we could perhaps open that url for autogenerator just for PUT. My reason is that:

• /services/{service}/plugins/
• /services/{service}/plugins/{plugin}

can be considered collection endpoints when doing PUT. This makes it possible to do:
PUT /services/demo/routes/demo-route

Which is nice. I wouldn't (though I have no strong feeling about it) support entity endpoints on that path anymore (e.g. PATCH, GET), just PUT (but that is debatable). PUT would just complete the POST that we already support.

[thibaultcha]

Not opposed to it, although:

• We should still support PATCH and GET on those endpoints
• We should still merge this in the meantime