Better performance lineage chunk_number assignment

[dachengx]

What is the problem / what does the code in this PR do

import straxen  # e9fe5dd7fb61fb537d35732730b41639ebc39980
import saltax  # e100810ad106351ef1180499889257d59c97ed90

st = saltax.contexts.sxenonnt(
    saltax_mode="salt",
    generator_name="ybe",
    recoil=0,
    rate=10,
    simu_mode="all",
    simulation_config="sr2_dev",
    corrections_version="global_v18",
    output_folder="strax_data",
)

run_id = "047967"
st.is_stored(run_id, "peaklets", chunk_number={"raw_records": [0, 1, 2]})

First get the efficiency of the above codes:

python -m cProfile -o output.prof test_chunks.py
gprof2dot -f pstats output.prof | dot -Tsvg -o profile.svg

The most significant part is

This is because when chunk_number is not None, strax before this PR will not cache plugins, so every time building the lineage of a higher plugin, the __get_plugin will be called.

Can you briefly describe how it works?

This PR makes sure that whenever chunk_number is None or not, the plugin (whose lineage does not include chunk_number) is cached. Then I designed a dedicated function to assign the chunk_number in lineage afterwards.

Can you give a minimal working example (or illustrate with a figure)?

Please include the following if applicable:

• Update the docstring(s)
• Update the documentation
• Tests to check the (new) code is working as desired.
• Does it solve one of the open issues on github?

Please make sure that all automated tests have passed before asking for a review (you can save the PR as a draft otherwise).

[dachengx]

This is essentially a bug. __deepcopy__ never works because deepcopy(plugin.deps) will also call __deepcopy__. plugin.deps is a dictionary of plugins.

[coveralls]

coverage: 88.915% (-0.04%) from 88.958%
when pulling ecaab74 on faster_add_lineage_to_plugin
into cd79adc on master.