[BugFix] Return FMP Error Messages

[deeleeramone]

WIP

1. Why?:

   • This PR addresses a bunch of instances where FMP returns empty and does not relay the error message.
     • Invalid API keys were returning empty instead of the error message.
     • Where multiple items were allowed, many are not checking that each symbol was being returned.

2. What?:

   • Refactor the HTTP requests to use methods that don't suppress the errors.

3. Impact:

   • Renovates a couple of standard models that are too FMP-specific and all mandatory fields.
   • Error messages from FMP are no longer suppressed.
   • FMPAnalystEstimates now accepts multiple symbols.

4. Testing Done:

   • Manual with bad key and good key, multiple items and single.
   • Not every endpoint raises a ClientResponseError, some will be empty and others are a dictionary with "Error Message" or "error" existing.

The examples below highlight the response difference between two, different, FMP endpoints with an invalid key.

obb.equity.ownership.insider_trading("AAPL")

OpenBBError: 401, message='Unauthorized', url=URL('https://financialmodelingprep.com/api/v4/insider-trading?symbol=AAPL&limit=500&page=0&apikey=********')

obb.equity.fundamental.cash("AAPL")

OpenBBError: FMP Error Message -> Invalid API KEY. Feel free to create a Free API Key or visit https://site.financialmodelingprep.com/faqs?search=why-is-my-api-key-invalid for more information.

[IgorWounds]

@deeleeramone Is there a particular need to have most standard fields set as Optional? Wouldn't we want to guarantee a certain set of fields for a particular endpoint that would make sense to always be present?

The async def get_one(symbol) repeats quite a few times through the fetchers and we can make it a helper so that it can be easily imported. It could, for example, take the symbol and an URL as an optional field or the like.

[deeleeramone]

The async def get_one(symbol) repeats quite a few times through the fetchers and we can make it a helper so that it can be easily imported. It could, for example, take the symbol and an URL as an optional field or the like.

They may appear to be repeating, and in the simplest cases it is, but there can be subtle differences and get_one is meant to be specific to the particular data that is being parsed - not universal. It is easier to maintain, and read the code, when it is all contained within the fetcher, IMO.

Is there a particular need to have most standard fields set as Optional? Wouldn't we want to guarantee a certain set of fields for a particular endpoint that would make sense to always be present.

The standard models should be usable for other providers that do not yet have this endpoint. In the past, I have wanted to add different providers to the earnings estimates but I could not because the model is only useful for FMP data. All those fields are quite likely to not be returned by another source.