Improve process logic in Camera2D

[lawnjelly]

The logic for internal process and internal physics process in Camera2D was very buggy and convoluted for historical reasons.

This is a cleanup to make the logic simpler and easier to follow.

Notes

• Moved this out of draft to try and get some eyes on..
• I've added an active flag rather than complicated the logic with lots of is_editor_hint spread all over the place. The active flag is set in one place, and makes it far easier to read / should make it less bug prone.
• This deprecates the ability to turn off processing by setting follow_smoothing to zero, and the old _set_old_smoothing function.

[lawnjelly]

While testing I noticed a slight vulnerability. The user could manually set the camera process mode using node functions, and bypass the camera logic. So I've added an extra check for this (_is_process_mode_correct called in the transform notification), it should be pretty cheap for an extra layer of protection. It also gives some insulation against further logic bugs in future.

We could place a WARN_PRINT_ONCE when this occurs? Wasn't sure whether this would be preferred.

[akien-mga]

The current code changes seem sensible to me. I'll try to test some projects to make sure that things behave as expected.

While testing I noticed a slight vulnerability. The user could manually set the camera process mode using node functions, and bypass the camera logic. So I've added an extra check for this (_is_process_mode_correct called in the transform notification), it should be pretty cheap for an extra layer of protection. It also gives some insulation against further logic bugs in future.

We could place a WARN_PRINT_ONCE when this occurs? Wasn't sure whether this would be preferred.

I think that's a general design issue which extends beyond just the Camera2D API. The internal process modes were added specifically to handle Node-internal logic that shouldn't be messed with by users. Yet, we still expose those methods to let them shoot themselves in the foot, just like they can queue_free() child nodes which are part of the private API of more complex nodes.
IMO it's OK as long as documentation is clear about it ("With great power comes great responsibility"), but some sanity checks here and there shouldn't hurt either.

[akien-mga]

IMO it's OK as long as documentation is clear about it ("With great power comes great responsibility"), but some sanity checks here and there shouldn't hurt either.

Documentation seems to be alright:

Warning: Built-in Nodes rely on the internal processing for their own logic, so changing this value from your code may lead to unexpected behavior. Script access to this internal logic is provided for specific advanced uses, but is unsafe and not supported.

[akien-mga]

Thanks!