Fix obs broadcast mismatch

[brandonwillard]

This PR casts new_shape values in pymc3.aesaraf.change_rv_size before calling RandomVariable.make_node, which prevents unnecessary Casts in the resulting RandomVariable's size parameter when new_shape is a constant.

As a follow-up and/or alternative, RandomVariable.make_node can be updated in Aesara and accomplish the same thing.

Closes #4652.

[twiecki]

Won't this cause problems if a DataFrame is passed?

[michaelosthege]

One of the first things in make_obs_var is another call to pandas_to_array, that's why this one can go away

[twiecki]

Suggested change

	# Make sure the new size is a tensor. This helps to not unnecessarily pick
	# Make sure the new size is an int64 tensor. This helps to not unnecessarily pick

[twiecki]

Should we also link to the issue here?

[michaelosthege]

It's discoverable through the commits.
But on #4696 we'll make a few more robustness changes to change_rv_size. I can link the issue when rebasing the reintro_shape branch.

[brandonwillard]

Unfortunately, the comment change introduced by commit 1716082 is actually more misleading than the original comment, because it makes a false statement instead of one that simply lacks context.

The Cast isn't avoided because new_size is a Variable—or any subclass thereof. For instance, passing new_size=at.as_tensor(np.array(..., dtype="int32")) to change_rv_size will still result in a Casted size parameter in the resulting RandomVariable node.

The Cast is avoided only when new_size isn't a Variable, and is an ndarray, a primitive Python numeric type, a tuple or list of numeric types, etc. In other words, the exact opposite of the new comment is true.

Here's the clarified form of the original comment:

    # Make sure numeric/NumPy `new_size` values are converted to int64, so that
    # the `RandomVariable`'s new `size` doesn't unnecessarily pick up a `Cast`.