Back-end Cache: should store/use task config

with get_task_instance, we send a string (key), ususally computed from Vorlesung-Nr, Aufgabe-Nr, Student-Nr.

The back-end cache uses this one key for two purposes:

• as a seed for the (deterministic pseudo) random generator for computation of instance
• as a key for the hashtable that contains all instances (It's not really a hashtable: in case of collision, we just overwrite)

These two purposes need to be separated.

We already started with #781 (improves key for store, to reduce collisions)

I have this use case: for exercise type "implement arithemtical expression by Goto program": while exercise is active, I notice that number of evaluation steps (for checking semantics) should be increased. But - problem instances should not be changed, since students are already working on them. So, we should not send a fresh key. But then we can never get fresh instances.

Proposed solution: include (hash of) task-config in the key for the store. (Do not change seed for generator.)

Then, when student next times works on his instance (for changed config), get_task_config will find nothing in the store, and computes an instance (using the same seed as before, so it should contain the same arithmetical expression) (but other instance parameters are copied from the config).

This only works if the generator does not use the parameters that were changed - which so happens in my use case. If the generator would have used the number of evaluation steps, then the problem would not have appeared in the first place.