Add a mechanism for clients to store metadata for no-recreate translation

[derekbruening]

Today, clients have to decode from cache instructions to deduce how to
restore state (combined with heap-stored metadata they may have kept). The
DR core, however, uses instrlist recreation metadata as part of its state
updates for mangling expansions, but does not make it easy for clients to
do the same. This issue covers trying to add a convenience mechanism to
pass data from the bb event w/ translating=true to the restore_state event.

[hgreving2304]

xref #2985 (a case where this will be needed)

[hgreving2304]

Main problem seems to be that for pending-deletion fragments, there is no ilist. So just adding a new restore_event callback that gets the ilist isn't enough. Would we need a restore_event_from_ilist AND restore_event_from_info? Is bb_event even called in this case?

[hgreving2304]

Also DR_EMIT_STORE_TRANSLATIONS.

[derekbruening]

Yes, to be like the core, clients would need to handle recreation from a list and restoring from stored info, so this is not all that convenient. Lower priority.

[abhinav92003]

Another use case for passing metadata to state restoration:

The current drreg state restore algorithm does not restore the app value of a gpr/aflags if they are dead at the fault instruction. This aligns with general drreg use. However, drreg should restore even dead gprs/aflags when drreg_options_t.conservative is set. It is difficult to achieve this without additional metadata to guide state restoration.

[derekbruening]

The original description is a little confusing above. Let's sharpen the focus here on the
no-instrlist case.

Also xref #5005 on drx's scatter-gather translation decode-only
approach being fragile; drreg's without an
instrlist is also fragile; drbbdup today bails (we'll have to remedy that for
b/254312104,i#5686 but it again will be fragile): without metadata from labels
in the recreated instrlist, clients are faced with extra complexity of decoding
and using heuristics to guess at their own instrumentation.

This issue is about improving the situation by having someone store ilist labels
for no-ilist fragments, just like DR stores pc ranges.

As an aside: note that we could not recreate even if we wanted to for cases
where clients have non-idempotent instrumentation; so even if we tried to
recreate for pending-delete fragments by making a code copy similar to our
selfmod copy we should still have to handle the no-recreate case.

Maybe we can assume that a small % of fragments are non-recreate, though we
should try to keep the storage cost for keeping metadata low. Maybe all we need
is a list of PC,label_value pairs.

Is the burden on the client for storing that? Xref complexities of per-bb data
vs bb deletion and tag re-use (esp for pending-delete). Maybe DR should provide
a user_data pointer (and drmgr multi-plexes or sthg) per fragment? Or DR
provides a stored translation-specific user_data.

[derekbruening]

drbbdup is a good test case here. drbbdup today bails on no-ilist: it does not implement decoding and heuristics to find the bbdup copies. Can easily trigger failure in the new drx-scattergather-bbdup test (for #5686) by having it return DR_EMIT_STORE_TRANSLATIONS.