[CAL][13] - implement NextSeqNum and GetSourceChainConfig

[ogtownsend]

core ref: 2a64fde7f18a7e6cae302f6bed4e71da1c5f42af

ConfigPoller Migration

• Migrates and implements NextSeqNum() in DefaultAccessor
• Adds GetSourceChainConfigs() to the ChainAccessor interface
• Begins separation of CCIPReader --> configPoller --> CCIPReader cyclic dependency and removes first function fetchFreshSourceChainConfigs() from the ccipReaderInternal interface. Complete removal of this interface will mean the cycle is broken
• For more context, see NONEVM-1865

Stack:

1. [CAL][1] - Add initial CAL scaffolding to CCIPReader with legacy accessor #978
2. [CAL][2] - Implement Metadata() and GetContractAddress() #980
3. [CAL][3] - Implement GetChainFeeComponents #985
4. [CAL][4] - Implement MsgsBetweenSeqNums() function in accessor #987
5. [CAL][5] - implement LatestMsgSeqNum #988
6. [CAL][6] - move SourceChainConfig to chainaccessor types #989
7. [CAL][7] - implement GetExpectedNextSequenceNumber #990
8. [CAL][8] - Some minor cleanup and renaming #999
9. [CAL][9] - Implement CommitReportsGTETimestamp, GetTokenPriceUSD, and GetLatestPriceSeqNr #1000
10. [CAL][10] - Implement Nonces and GetChainFeePriceUpdate #1014
11. [CAL][11] - Implement ExecutedMessages for chain accessor #1017
12. [CAL][12] - Implement Sync() in DefaultAccessor #1031
13. ➡️ [CAL][13] - implement NextSeqNum and GetSourceChainConfig #1049
14. [CAL][14] - add chain accessors to plugin factory params #1052

[winder]

I'm a little on the fence about putting this in the interface.

On one hand it avoids any confusion about whether the data is fresh or cached, so it's much clearer than the code that you've replaced. On the other, it's sort of an implementation detail because a non-EVM chain family might choose to store the next seq number in a different location.

[ogtownsend]

hmm, but accessor.NextSeqNum() calling accessor.GetSourceChainConfigs() is more of an implementation detail of this DefaultAccessor rather than the entire ChainAccessor interface

By adding GetSourceChainConfigs() to the CAL interface we're just saying all chains will need to provide a way to fetch source chain configs, but all future accessors won't require that NextSeqNum() calls GetSourceChainConfigs()...if that makes sense

[github-actions]

Metric	ogt/cal-13-implement-NextSeqNum-and-add-GetSourceChainConfig	main
Coverage	69.7%	69.7%