Explicitly naming variables and blocks in trace

I have been looking at traces (IOSSReader and ExodusIIReader), and both explicitly set variables and blocks. However, this is both redundant and not necessary, as the reader turns them all on by default. Here is the code of interest for the IOSSReader from 5.10.0-RC1:

canex2 = IOSSReader(registrationName='can.ex2', FileName=['/Applications/PV/can.ex2'])
canex2.ElementBlocks = ['block_1', 'block_2']
canex2.NodeBlockFields = ['accl', 'displ', 'vel']
canex2.ElementBlockFields = ['eqps']

Why do we even need to set the ElementBlocks, NodeBlockFields or ElementBlockFields? It has confused numerous users, and me until I looked at it closely. I would like to propose that the trace recorder NOT set these, but just add a comment in case users want to set blocks or fields. For instance,

canex2 = IOSSReader(registrationName='can.ex2', FileName=['/Applications/PV/can.ex2'])
# canex2.ElementBlocks = ['block_1', 'block_2']
# canex2.NodeBlockFields = ['accl', 'displ', 'vel']
# canex2.ElementBlockFields = ['eqps']

The reason to not explicitly set these is that the same trace is more generic, and still works correctly. If a user wants to find out what the Fields are, they can use the GetProperty command.

@utkarsh.ayachit @cory.quammen

I believe the XDMFReader exhibits similar behavior with respect to its PointArrayStatus and CellArrayStatus attributes.

https://gitlab.kitware.com/paraview/paraview/-/issues/21114