add consistency tests for prototype container transforms

[pmeier]

Per title.

When designing the prototype API, we intentionally only used torch's random capabilities to generate parameters everywhere. However, on the legacy API there are two transforms that don't:
There are two outliers:

• RandomChoice:
  

  vision/torchvision/transforms/transforms.py

  Lines 565 to 567 in cc9ceb5

  	def __call__(self, *args):
  	t = random.choices(self.transforms, weights=self.p)[0]
  	return t(*args)

• RandomOrder:
  

  vision/torchvision/transforms/transforms.py

  Lines 548 to 553 in cc9ceb5

  	def __call__(self, img):
  	order = list(range(len(self.transforms)))
  	random.shuffle(order)
  	for i in order:
  	img = self.transforms[i](img)
  	return img

For the former we can at least test for p=0 and p=1, but for the latter I have no idea how to test other than manually. Given that code is very simple, I want to avoid complicated mocking like we are doing in #6519.

The equivalent logic on the prototype transforms is:

• RandomChoice:
  

  vision/torchvision/prototype/transforms/_container.py

  Lines 66 to 69 in cc9ceb5

  	def forward(self, *inputs: Any) -> Any:
  	idx = int(torch.multinomial(torch.tensor(self.probabilities), 1))
  	transform = self.transforms[idx]
  	return transform(*inputs)

• RandomOrder:
  

  vision/torchvision/prototype/transforms/_container.py

  Lines 79 to 84 in cc9ceb5

  	def forward(self, *inputs: Any) -> Any:
  	sample = inputs if len(inputs) > 1 else inputs[0]
  	for idx in torch.randperm(len(self.transforms)):
  	transform = self.transforms[idx]
  	sample = transform(sample)
  	return sample

Basically we need to make sure that they generate the same distribution. I confirmed that they are consistent visually.

Apart from the testing, I also fixed a consistency bug in RandomApply.

[pmeier]

We don't need to create the transform for ever image.

[pmeier]

I don't really understand why RandomApply needs to support multiple transforms. I've re-added it here for BC, but I think we should deprecate this in favor of what our internal _RandomApplyTransform does. If the user needs multiple transforms, they can simply wrap them in a Compose before passing it to RandomApply.

[vfdev-5]

I agree. Maybe, we can extend Compose with p argument to cover RandomApply feature...

[datumbox]

I think for now we should keep it and review on the future what we want to deprecate. It's true that many of the transforms can be written as a combination of other transforms. For example, the majority of the Random* transforms that support a p probability could have used the RandomApply. Unfortunately dropping some of these functionalities not only breaks BC but also leads to more verbose code. So we should have a separate discussion over what should be deprecated and why.

[vfdev-5]

Looks ok to me, thanks @pmeier