verification and validation of intent should 'logically begin' after 202 is returned

[marten-de-vries]

I encounter this (among others) at https://websub.rocks/subscriber/100. My original POST subscription request (as defined in # 5.1 Subscriber Sends Subscription Request) gets answered with a 400 code. The body includes the following explanation:
{"error":"verification_failed","error_description":"The callback URL did not confirm the verification request.","code":0,"callback_response":false,"type":"error"}

This seems in violation of the spec (specifically the last quoted MUST NOT):

If a hub finds any errors in the subscription request, an appropriate HTTP [RFC7231] error response code (4xx or 5xx) MUST be returned. In the event of an error, hubs SHOULD return a description of the error in the response body as plain text, used to assist the client developer in understanding the error. This is not meant to be shown to the end user. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers). However, since verification and validation of intent are asynchronous steps that logically begin after the HTTP response has been returned, the HTTP response MUST NOT depend on the process or outcome of verification or validation.

It seems like the test should return 202, and only then hit my callback. I discovered this as my test procedure actually only exposed the callbacks after a 202 response is received. I've fixed that as it depends on the (localhost) subscriber outracing the (external) hub in getting them up (which is not guaranteed, even though it's likely), but that doesn't mean there isn't a bug on the test suite side too.

(Moved from w3c/websub#122)