Fix mutex-meet for malloc after thread creation

[michael-schwarz]

The issue in #1489 was that the global invariant for the blob was still bot, making the meet deadcode.

TODO:

• mutex-meet-atomic privatization still unsound
• Verify if these are really all changes needed for mutex-meet-atomic (It seems weird that no handling of these cases is necessary in get_mutex_global_g_with_mutex_inits_atomic CC: @sim642)

Closes #1489

[sim642]

• Verify if these are really all changes needed for mutex-meet-atomic (It seems weird that no handling of these cases is necessary in get_mutex_global_g_with_mutex_inits_atomic CC: @sim642)

That doesn't restrict unprotected invariants to a single variable, which if missing, causes bot. It might just be pushing the issue further down the line though: at some point there could still be an Apron assignment from that variable to something else. But maybe the variable will never be missing, rather some meet will just unify it to top?

[sim642]

mutex:[__VERIFIER_atomic] also starts out with bottom (env: [||]), so that's not the difference I suspect. Rather, the difference comes from this check:

analyzer/src/analyses/apron/relationPriv.apron.ml

Lines 500 to 504 in 896f236

	if not (RD.mem_var get_mutex_inits' g_var) then (* TODO: is this just a workaround for an escape bug? https://github.com/goblint/analyzer/pull/1354/files#r1498882657 *)
	(* This is an escaped variable whose value was never side-effected to get_mutex_inits' *)
	get_mutex_global_g
	else
	RD.join get_mutex_global_g get_mutex_inits'

get_mutex_global_g_with_mutex_inits_atomic doesn't have such condition and always does the join (with non-bottom), which makes everything fine.
I wonder if also checking RD.mem_var get_mutex_global_g g_var before doing this would be a fix closer to the existing logic.