Add a new interface InitToolCallbackResolverErrorHandler as extension for customized actions when ToolCallbackProvider.getToolCallbacks() fail on application starting up

[waltertan1988]

This extension is to fix issue in below scenario for Spring-AI v1.0.1:

Step 1: Application as MCP client that needs to call MCP server in SSE mode.
Step 2: The running MCP server is down, or the network between MCP client and MCP servers is unavailable.
Step 3: When MCP client application starting up, it try to fetch ToolCallbacks immediately from MCP server but failed by reasons in Step 2.
Step 4: MCP client application cannot be start up until problems in Step 2 are resolved.

Below is the related error detail:

Suppressed: java.lang.Exception: #block terminated with an error
		at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:104)
		at reactor.core.publisher.Mono.block(Mono.java:1779)
		at io.modelcontextprotocol.client.McpSyncClient.listTools(McpSyncClient.java:228)
		at org.springframework.ai.mcp.SyncMcpToolCallbackProvider.lambda$getToolCallbacks$3(SyncMcpToolCallbackProvider.java:133)
		at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273)
		at java.base/java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(AbstractList.java:722)
		at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
		at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
		at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
		at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
		at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
		at org.springframework.ai.mcp.SyncMcpToolCallbackProvider.getToolCallbacks(SyncMcpToolCallbackProvider.java:138)
		at org.springframework.ai.model.tool.autoconfigure.ToolCallingAutoConfiguration.lambda$toolCallbackResolver$0(ToolCallingAutoConfiguration.java:68)
		at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
		at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708)
		at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
		at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
		at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
		at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
		at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
		at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
		at org.springframework.ai.model.tool.autoconfigure.ToolCallingAutoConfiguration.toolCallbackResolver(ToolCallingAutoConfiguration.java:68)
		at java.base/java.lang.reflect.Method.invoke(Method.java:580)

Actually, when application starting up, as long as it needs to fetch ToolCallbacks immediately, no matter
(1) by network from any remote server(may be database, mcp server and so on) , or
(2) from local ToolCallbackProvider which has limitation logic that deny getting ToolCallback,
the same issue occurs. (#3232 is similar issue in MCP).

In distributed systems, it is very normal that remote-servers are temporarily unavailable and they should not impact the client-sides start up. As a result, we need a mechanism to let developers decide what actions they prefer to take for the error, or even use other ToolCallbacks as fallback replacement on demand. This is exactly what InitToolCallbackResolverErrorHandler does.

Pls kindly help review and approve this PR. Tks.

[Kehrlann]

#4459 addresses this issue in a different way.

[waltertan1988]

#4459 addresses this issue in a different way.

It seems the core difference between these 2 ways is whether it is reasonable to retain the StaticToolCallbackResolver that supports loading ToolCallbacks immediately, right?