Remove _fullInput and other dead transforms code

[emilykl]

Addresses #7250

• The trace._fullInput field existed solely for keeping track of the original input trace after applying defaults but before applying transforms
• Now that the transforms feature has been fully removed (see Drop transforms from the API #7240, Remove transforms from bundles #7254), trace._fullInput is the same as trace
• This PR changes all references to trace._fullInput to simply trace, and adjusts logic accordingly
• Also removes trace._indexToPoints which was likewise only used for transforms
• Removes some other dead transforms code which was unused but still in codebase
• Finally, updates or removes tests which referenced trace._fullInput or transforms

This PR should have zero user-facing impact.

[camdecoster]

Looks good! Two things:

• Could you add a draftlog? Since this removes the deprecated code, it would be good to note that.
• Could you do a sweep for comments that mention transforms or _fullData?

[emilykl]

• Could you add a draftlog? Since this removes the deprecated code, it would be good to note that.

Sure, I can add a draftlog, it could help with debugging later, so not a bad idea. But the removed code was already inaccessible so I don't expect any user-facing changes.

• Could you do a sweep for comments that mention transforms or _fullData _fullInput?

Good idea! 0 matches for fullInput, but a bunch of matches for transforms. I'll look at each of those more closely and modify or remove.

[alexcjohnson]

all these traceOut._length = null statements refer to disabling transforms... I'm pretty sure they can all be removed after #7240, specifically these lines.

[emilykl]

@alexcjohnson Thanks, that's helpful. I considered removing them but wasn't confident, since I do see trace._length referenced in some places that are unrelated to transforms. But I think _length being undefined vs. null would behave identically in all of those cases anyway. So I'll try just removing all of the traceOut._length = null statements and make sure everything passes.

[emilykl]

@alexcjohnson Whoops, looks like we do actually specifically test for trace._length being numeric or null 😅

Does anything in that test or comment change your opinion about removing? Or should we just delete that part of the test?

[alexcjohnson]

Ah ok - the "simplifying calc/plot logic later on" part I can get behind, and there is one danger in leaving it undefined rather than setting it explicitly to null: the relinkPrivateKeys step can in principle bring back in an old _length that was valid for the data that used to be in a trace but has since changed. So yeah, let's leave these in place unless and until we figure out which trace types actually have such logic.

[emilykl]

Ok!

[alexcjohnson]

LGTM! Just a couple more items I bet we could remove, as noted above.