The sub-command "delete" fails to delete printer(s)

[tangyanli]

Describe the bug
The sub-command "delete" fails to delete printer(s)

To Reproduce
Steps to reproduce the behavior:

1. Start legacy-printer-app.
2. Add a printer named "legacy-1" on web page or by the "add" sub-command.
3. Call sub-command "delete" to delete the new added printer:
   legacy-printer-app delete -d legacy-1
4. The terminal display below error message:
   legacy-printer-app: Unable to get information for printer: successful-ok

More behavior

1. The new added printer can be deleted on the web page.
2. If I shutdown and restart the printer-app again, then the printer "legacy-1" can be deleted by the "delete" sub-command.

System Information:

• OS: Ubuntu22.10
• Browser: Firefix
• Version: pappl-v1.4.x

Additional context
At the client side, in the function _papplMainloopDeletePrinter, the acquired printer_id is 0.

	printer_id = ippGetInteger(ippFindAttribute(response, "printer-id", IPP_TAG_INTEGER), 0);
	ippDelete(response);

	if (printer_id == 0)       ★ printer_id is 0
	{
		_papplLocPrintf(stderr, _PAPPL_LOC("%s: Unable to get information for printer: %s"), base_name, cupsGetErrorString());
		httpClose(http);
		return (1);
	}

At the pappl server side, the backtrace is as below

ipp_create_printer()
    papplPrinterCreate(system, printer_id = 0, ...) 
        ippAddInteger(printer->attrs, IPP_TAG_PRINTER, IPP_TAG_INTEGER, "printer-id", printer_id)   ★ the value of "printer-id" attribute is set as 0
        _papplSystemAddPrinter(system, printer, printer_id)
            printer->printer_id = system->next_printer_id ++    ★ the printer_id is reset. But the "printer-id" in the printer->attrs is still 0.

[michaelrsweet]

OK, this should now be fixed.

[michaelrsweet]

(only affected new printers, printers that were loaded then got the correct ID)