Remove loadConfigStrict

[StefanBratanov]

PR Description

loadConfigStrict and ignoreUnknownConfigItems is only used in tests. When removed getTtfbTimeout and getRespTimeout, there were failing tests since some were using loadConfigStrict, but adding to KEYS_TO_IGNORE in SpecConfigReader will cause incompatibility between old versions of VC and new BN. Not sure what is a good approach in this situation. We can keep the old getters unused in NetworkingSpecConfig, but prefer to have them removed for clarity, but without causing incompatibilities.

Fixed Issue(s)

N/A

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[rolfyone]

why are we removing this? maybe at least move it to testing rather than remove, its kinda important w'ere trying to validate our local configuration...

[StefanBratanov]

why are we removing this? maybe at least move it to testing rather than remove, its kinda important w'ere trying to validate our local configuration...

I was thinking how to remove getTtfbTimeout and getRespTimeout from NetworkingSpecConfig without tests failing or without causing compatibility issues (if we put in deprecated fields, the spec endpoint won't return them)

[tbenr]

I think it is valuable in general to use it in tests because there we want to be less permissive and early detect potential issues. That's a general statement but I don't know if in practice we will use it after you changes.

[StefanBratanov]

I think it is valuable in general to use it in tests because there we want to be less permissive and early detect potential issues. That's a general statement but I don't know if in practice we will use it after you changes.

Yeah, I have rethought and it makes sense to keep it, but the question remains how to deal with deprecated fields and not failing tests.

[StefanBratanov]

Will close and remove deprecated fields later