Do not dynamically assign modProcessorResponse to modConnectorResponse

[opengeek]

What does it do?

Assign the processor result to a local variable rather than dynamically creating a "response" property on the modConnectorResponse class.

Why is it needed?

In PHP 8.2, dynamically assigning a property to a class is deprecated. When calling runProcessor, the result is only used within the outputContent() method, so there is no need to assign the result from runProcessor to a property of modConnectorResponse dynamically or add a property to modConnectorResponse to hold the result.

How to test

Confirm no deprecated warnings are logged when running a processor in a connector.

Related issue(s)/PR(s)

Port of #16563 to 3.0.x/3.x

[Mark-H]

I'm kinda worried this introduces a breaking change where people may have relied on $response->response containing the output of the processor, although seeing just the file out of context I'm not 100% sure if that applies here or if that was in one of the other response classes (modProcessorResponse?)

For BCs sake, could we instead define the response as a public property?

It is definitely a good thing to get rid of dynamic variables.

[opengeek]

I'm kinda worried this introduces a breaking change where people may have relied on $response->response containing the output of the processor, although seeing just the file out of context I'm not 100% sure if that applies here or if that was in one of the other response classes (modProcessorResponse?)

For BCs sake, could we instead define the response as a public property?

It is definitely a good thing to get rid of dynamic variables.

There's nowhere it could be used as far as I can tell. If I'm wrong, I'll be glad to change it, but I don't see any valid way it could be used. The result of modProcessorResponse->getResponse is assigned to the body, which is a public property, in this same block of code if the processor produces an actual modProcessorResponse object.