No, there is not an immediate workaround to this :-(
The mechanism by which they measure that 'callout depth' is by transmitting an HTTP header on requests originating from Apex,
Sfdc-Stack-Depth: 1 - if you try and trick the platform by explicitly setting this header to
'' etc, you'll find the value is very sticky!
Unfortunately for us, there is a good business reason behind this "feature" on Salesforce' part. It is by design, to prevents callouts from blocking threads between multiple orgs / instances.
(hopefully this sequence diagram illustrates the intention; as an HTTP callout could take a while, the number of loopback connections is restricted to 1, otherwise imagine the DoS implications)
You might be able to overcome this issue if your
B callout were read-only and its contents were updated infrequently.
You could schedule a batch process to regularly perform the callout and avail its response in a Document (or such). Then read that Document when responding to
A, decoupling the two. But I admit that may be unlikely in your case...