TreeMsgLikelihoods should swap NamedTuple for Tuple

[dehann]

Could have a similar compile time implication as was found in:

• CCW.params NamedTuple->Tuple #1565
• Ensure tree construction code is only compiled once, #1513
• Is there any example for mult-architecture support [JuliaGPU] Caesar.jl#835

[Affie]

Are you referring to sender in this?

IncrementalInference.jl/src/entities/CliqueTypes.jl

Lines 43 to 56 in 60134f9

	mutable struct LikelihoodMessage{T <: MessageType} <: AbstractPrior
	sender::NamedTuple{(:id,:step),Tuple{Int,Int}}
	status::CliqStatus
	belief::Dict{Symbol, TreeBelief} # will eventually be deprecated
	variableOrder::Vector{Symbol}
	cliqueLikelihood::Union{Nothing,SamplableBelief} # TODO drop the Union
	msgType::T
	hasPriors::Bool
	# this is different from belief[].inferdim, as the total available infer dims remaining during down msgs -- see #910
	childSolvDims::Dict{Int, Float64}
	# calc differential factors for joint in the child clique
	jointmsg::_MsgJointLikelihood
	# diffJoints::Vector{NamedTuple{(:variables, :likelihood), Tuple{Vector{Symbol},DFG.AbstractRelative}}}
	end

It is good as a NamedTuple.

[dehann]

Looking at .sender I think that should be okay, since the type is hard coded.

Not recalling exactly, but upon looking through this again I think it was actually the NamedTuple in the MsgRelativeType const that might be causing the Bayes tree compile time delays.

Just quickly, I made a very small runtime improvement:

• MsgRelativeType as anonymous-concrete when able #1579

But does notyet get rid of the potential NamedTuple compile time issue on tree message passing.

I'm also worried about the non-concrete union type on .cliqueLikelihood