Fixes the issue discussed in !607 (merged) by improving the way the unique track ID is computed. The previous implementation added the first and last LHCbID to the memory location. This did not always produce a unique ID, as with just the correct combination of addresses and LHCbIDs fake matches could be made.
This MR updates the code to simply use the tracks memory address. This fix is known not to be bullet proof as in theory it is possible for
- A track to be created.
- Use the tool on that track
- Delete that track, make a new one.
- Use the new track.
If at step 3 the same memory address is used, the tool will wrongly use the original cache.
In the current production code, this I am told is not done. The tool is only ever used on unchanging tracks in fixed final containers. In this scenario the memory address should be robust enough. An error is printed if the tool ever is passed a track with no parent container.
Note this fix is only needed for the rest of Run II. For Run III the whole current implementation ever needs to change completely, or no longer be used.