[16.0] use experimental nfelib version with SOAP support

[rvalyi]

Esse é um refator principalmente dos módulos l10n_br_fiscal_dfe e l10n_br_nfe para funcionar diretamente com o novo suporte SOAP da nfelib e não depender mais de erpbrasil.edoc. Eh um POC rascunho, não tem pressa em mesclar. Porem eu acho que temos que ter isso bem definido até a reforma tributaria do inicio de 2026 e para ver a v18 também...

1. Esse novo suporte do SOAP na nfelib pode ser visto nesse PR
2. Esse suporte do SOAP é feito usando também a lib brazil-fiscal-client que é um substituto limpo do erpbrasil.transmissao que não depende da lib Zeep mas usa praticamente apenas a lib Requests para fazer os queries SOAP (depende de xsdata que já usamos na localização, mas o cliente SOAP usa quase que apenas do Requests).
3. Para ficar compatível com versões recentes da nfelib, fiz essa branch frankenstein do erpbrasil.edoc que "vendoriza" os binding legacy de transmissão generateDS na pasta src/erpbrasil/nfelib_legacy/v4_00

Já que o l10n_br_fiscal_dfe foi mesclado pela Kmee sem nem nunca funcionar direito, eu diria que poderíamos fazer o refator no l10n_br_fiscal_dfe sem muito questionamento. Juntando com #4096 , o l10n_br_fiscal_dfe poderia até se chegar num estagio Production/Stable...

Agora para o l10n_br_nfe onde a parte SOAP é critica, temos que cogitar bem o que podemos fazer. Algumas alternativas na mesa:

1. testar muito e substituir o erpbrasil.edoc pelo nfelib mesmo. No caso como na Akretion, Escodoo e Engenere não temos clientes usando NFCe, essa parte da NFCe seria a parte onde existiria o maior risco de regressão. (Porem se algum dia queremos um Odoo popular pro varejo não teria como ser usando libs mal feitas como erpbrasil.edoc... Pois varejo não pode dar o menor pepino em produção ou para atualizar... A parte da NFe eu accredito que seria possível testar bem em produção e garantir que ta pelo menos melhor.
2. usar o campos select processador_edoc do res.company para escolher que lib faz a transmissão. So que se a gente foi fazer isso, em vez de uns +450/-450 linhas de diff, seria fácil uns +800/-800 linhas de diff, ou seja um acréscimo de umas 500 linhas de código quase redundante legacy para agradar de forma temporária quem talvez não ta agregando tanto ao projeto hoje... Neste caso, os testes provavelmente seriam apenas com uma so dessas duas lib, ou seja provavelmente a transmissão com erpbrasil.edoc não seria mais testada aqui (e como ela não ta testado no repo da lib, não iria funcionar por muito mais tempo...)
3. extrair a transmissão pelo erpbrasil.edoc num modulo extra tipo l10n_br_nfe_legacy_soap ou algo assim.

Por fim quais seriam as vantagens de substituir o erpbrasil.edoc pela nfelib:

1. o erpbrasil.edoc foi copiado as pressas do Pysped https://github.com/aricaldeira/PySPED/blob/python3/pysped/nfe/processador_nfe.py em 2018 pelo @mileo depois de uma briga entre a Kmee e o Ary, o autor da lib Pysped. Mas a real é que o @mileo já demonstrou não parecer ter a competência tecnica para assumir a pilotagem da lib, nem tem a dedicação. A lib erpbrasil.edoc quase que sempre foi sem teste, precisou o @antoniospneto para adicionar alguns testes anos depois. 7 anos depois da sua criação erpbrasil.edoc quase que não tem nehnuma adoção fora do OCA/l10n-brazil, so tem 17 estrelas e quase nem tem contribuição... O código continua bem feinho... Faz 2 anos que anunciamos que iríamos tirar os bindings generateDS na nfelib e até agora não houve atualização no erpbrasil.edoc....
2. Hoje erpbrasil.edoc se aparenta mais a um barco desgovernado: não tem capitão e o mileo sempre deu carta branca para completos iniciantes fazer "contribuições" a vontade na lib como se aconteceria um tipo de crowd sourcing de alguma coisa decente... Exemplos com as novas dependências infinitas com as lib de NFSe super mal feitas. Não tem nenhuma vigilância com a atualização e o control das dependências legacy. Não tem nenhuma preocupação em tornar o API mais consistente e o código do nível da OCA. Não adiante a OCA se preocupar em ter uma qualidade top e a gente depender de libs feitas e controladas por iniciantes que nunca conseguiriam contribuir algum código na OCA... Acaba sendo o ponto fraco da localização OCA toda.

Por fim, esse PR é meio que o refator mínimo para ter os testes passando, é meio que o POC. Eh claro que muita coisa poderia ser melhorado. Inclusive, numa hipótese onde conservamos o erpbrasil.edoc no modulo l10_br_nfe ou num modulo extra, poderia se cogitar alguns refatores para tentar mutuzalizar o código adiante. No nfelib, eu procurei replicar o mais possível o API do pysped/erpbrasil.edoc. Porem eu anotei vários lugares onde seria possível mudar para um API mais amigável. Em especial: deixar a lib cuidar da assinatura (pros eventos inclusive), chamar o API apenas com parâmetros simples, naõ ter que montar bindings fora da lib para passar como parâmetros, API para transmissão em lote etc...

cc @OCA/local-brazil-maintainers

[OCA-git-bot]

Hi @renatonlima, @mileo, @marcelsavegnago,
some modules you are maintaining are being modified, check this out!