Defer translated string evaluation on validators.

[doctoryes]

Description

This PR originated with the changes in this PR: #3438 . However, that PR stalled and was closed. This PR proposes the same change again - defer the error message string evaluation until the messages are actually used.

As stated in the original PR, our project uses a forked version of DRF only because of the issue described in #3354 . Our fork contains only one custom change - the one in this commit: edx@3c72cb5 Our project (Open edX) performs a non-standard startup which causes DRF to be imported before the Django translation infrastructure is initialized.

An initial attempt to fix this issue was made in this PR: #3407 - but was replaced by the more recent PR: #3438

@carltongibson @xordoquy FYI
@bmedx @macdiesel FYI

Closes #3354

[xordoquy]

Seems this went under my radar again.
Thanks for bringing it back !
PR needs to review but looks good at first sight.

[carltongibson]

OK. Lets have this. What a nice one to clear up!

I added a docstring to CustomValidatorMessage just so we can remember what this is all for in two years time.

@doctoryes @xordoquy Thanks for the work on this! Good one. 👍

[mehdipourfar]

This commit makes serialization process 3 times slower. In my project, I inspected that serializing about 160 objects takes around 1500 milliseconds. After profiling, I've found out that the most time consuming tasks are related to using of Django's lazy function:

ncalls tottime percall cumtime percall filename:lineno(function)
9126 0.428 0.000 0.865 0.000 functional.py:82(prepare_class)
847785 0.343 0.000 0.343 0.000 {built-in method builtins.hasattr}
2724/2562 0.198 0.000 0.233 0.000 fields.py:627(deepcopy)
267546 0.065 0.000 0.065 0.000 {built-in method builtins.setattr}
4386 0.057 0.000 0.080 0.000 {built-in method builtins.build_class}
8244 0.056 0.000 0.071 0.000 fields.py:320(init)
232458 0.048 0.000 0.048 0.000 functional.py:102(promise)
4431 0.039 0.000 0.273 0.000 field_mapping.py:66(get_field_kwargs)
158386 0.039 0.000 0.045 0.000 {built-in method builtins.getattr}
795 0.031 0.000 1.729 0.002 serializers.py:989(get_fields)
4386 0.024 0.000 0.024 0.000 functional.py:57(proxy)
.
.
.

After removing the usage of lazy function in restframework source code, my serialization process finishes after around 500 miliseconds.

[rpkilby]

Hm. I think this can be resolved by relying on the ValidationError to format the message, instead of us. Basically, we need to change our error messages to use %(limit_value)s and let the ValidationError format the message, instead of providing a lazily formatted {max_value}. @mehdipourfar - do you think you'd be up for creating a PR?

Although, I guess this would create a compatibility issue w/ users who already override their custom messages with their own format strings. Maybe we could detect this? idk if there's a reliable way of doing so.

Then again, detecting this would defeat the purpose of lazy evaluation.

[mehdipourfar]

Hi @rpkilby
I have created a PR:
remove usage of django's lazy function for error messages

[rpkilby]

Thanks.